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Предисловие 


В результате взрывного развития Internet, беспроводных видов связи и сетей co- 
размерно увеличилось число программистов и инженеров, занимающихся разра- 
боткой сетевых приложений. Программирование TCP/IP может показаться об- 
манчиво простым. Интерфейс прикладного программирования (API) несложен. 
Даже новичок может взять шаблон клиента или сервера и создать на его основе 
работающее приложение. 

К сожалению, нередко после весьма продуктивного начала неофиты начинают 
понимать, что все не так очевидно, а созданная ими программа оказывается и мед- 
ленной, и нестабильной. В сетевом программировании есть множество «темных 
уголков» и трудно понимаемых деталей. Цель этой книги - ответить па возникаю- 
щие вопросы и помочь разобраться с тонкостями программирования TCP/IP. 

Прочитав данную книгу, вы научитесь преодолевать трудности сетевого про- 
граммирования. Здесь будут рассмотрены многие вопросы, на первый взгляд, лишь 
отдаленно связанные с теми знаниями, которыми должен обладать программист 
сетевых приложений. Но без понимания таких деталей не разобраться в том, как 
сетевые протоколы взаимодействуют с приложением. Ранее казавшееся загадоч- 
ным «поведение» приложения при ближайшем рассмотрении становится совер- 
шенно понятным, решение проблемы лежит на поверхности. 

Книга построена несколько необычно. Типичные проблемы представлены в виде 
серии советов. Разбираясь с конкретным вопросом, вы будете переходить к изуче- 
нию того или иного аспекта TCP/IP. К концу главы вы не только решите частную 
задачу, но и углубите понимание того, как работают и взаимодействуют с прило- 
жением протоколы TCP/IP. 

Разбивка книги на отдельные советы в какой-то мере лишает текст логической 
последовательности. Чтобы помочь вам сориентироваться, в главу 1 помещен пу- 
теводитель, описывающий расположение материала. Получить общее представле- 
ние об организации книги поможет также оглавление, в котором перечислены все 
советы. Поскольку каждый совет дан в повелительном наклонении, оглавление 
можно считать списком рецептов. 

С другой стороны, такая организация материала позволяет использовать KHH- 
гу в качестве справочника. Столкнувшись в повседневной работе с какой-либо 
проблемой, вы можете обратиться к соответствующему совету, чтобы вспомнить 
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ее решение. Многие темы затрагиваются в нескольких советах, иногда под раз- 
ным углом зрения. Такое повторение помогает усвоению сложных концепций, 
проясняя мотивы тех или иных решений. 


Аудитория 


Данная книга предназначена, главным образом, начинающим и программистам 
среднего уровня, но даже опытные специалисты найдут в ней много полезного для 
себя. Хотя и предполагается, что читатель знаком с сетями и основами АР] на базе 
сокетов, в главе 1 приводится обзор элементарных вызовов АРГи их использования 
для создания примитивного клиента и сервера. В совете 4 более детально рассмот- 
рены модели клиента и сервера, поэтому даже читатель с минимальной подготовкой 
сможет извлечь из представленного материала практическую пользу. 

Почти все примеры написаны на языке С, безусловно, необходимы базовые 
навыки программирования на этом языке для понимания приведенных в книге 
программ. В совете 31 представлены некоторые примеры на языке Perl. Ho, впро- 
чем, предварительное знание Рег| необязательно. Здесь встречаются и небольшие 
примеры на языках командных интерпретаторов (shell), но и для их понимания 
знакомства с зБе-программированием не нужно. 

Материал для изучения подан по возможности максимально независимо от 
платформы. За немногими исключениями, приводимые в примерах программы 
должны компилироваться и работать на любой платформе UNIX или Win32. Но 
программисты, которые используют системы, отличные от UNIX и Windows, тоже 
могут без особых трудностей применять примеры на своей платформе. 


Принятые в книге соглашения 


По ходу изложения приведены небольшие программы для иллюстрации раз- 
личных аспектов исследуемой проблемы. Здесь будут использоваться следующие 
соглашения: 


О текст, который набирает пользователь, печатается полужирным моноши- 
ринным шрифтом; 

О текст, который выводят системы, печатается обычным моноширинным 
шрифтом; 

О комментарии, не являющиеся частью ввода или вывода, печатаются кур- 
сивным моноширинным шрифтом. 


Пример из совета 9: 


bsd: $ Есрки localhost 9000 

hello 

получено сообщение 1 печатается после пятисекундной задержки 
здесь сервер остановили 

hello again 

tcprw: ошибка вызова readline: Connection reset by peer (54) 

bsd: $ 


Оформление ПН ВИ И И ЕЕ 


Обратите внимание на приглашение командного интерпретатора, содержащее 
имя системы. Предыдущий пример исполнялся на машине с именем bsd. 

В рамке дается описание вводимой в рассмотрение новой функции АРІ ~ соб- 
ственной или системного вызова. Стандартные системные вызовы обводятся 
сплошной рамкой: 


#incluđde <sys/socket.h>  /* UNIX */ 
finclude «winsock2.h» / * Windows */ 


int connect ( SOCKET s, const struct sockaddr *peer, int peer len); 


Возвращаемое значение: 0 — нормально, —1 (UNIX) или не 0 (Windows) — 
ошибка. 


Разработанные автором функции обведены пунктирной рамкой: 


АН авы" а а 


d&include "etcp.h" 
SOCKET tcp, server( char *host, char *port); 


| Возвращаемое значение: сокет в режиме прослушивания (в случае ошибки За- 
‚вершает программу). 


а т E 


Примечание Таким образом отмечены попутные замечания и дополнитель- 
ный материал. При первом чтении подобный материал можно 
пропускать. 


Наконец, URL подчеркивается: 


http;//www.freebsd.org. 
Исходные тексты и список исправлений 


Исходные тексты всех встречающихся в книге примеров представлены на сай- 
те издательства «ДМК-Пресс» http://www.dmk.ru. Вы можете загрузить их на свой 
компьютер и поэкспериментировать. На этом сайте находятся каркасы программ 
и код библиотечных функций. 


Оформление 


Мне очень нравится оформление книг Ричарда Стивенса*. Приступая к работе 
над этой книгой, я попросил у Рича разрешения скопировать его стиль. Рич со 
свойственным ему великодушием не только не возражал, но даже посодействовал 
этой «краже», прислав мне макросы для форматера GROFF, которыми он пользо- 
вался при наборе своих книг. 

Если вам понравится это издание, то благодарить следует Рича. В противном 
случае загляните в любую из его книг, чтобы понять, к чему я стремился. 


* Речь идет о трехтомном издании «TCPAIP Illustratede и двухтомном «UNIX Network Program- 
ming», — Прим. перев. 
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лигену (Bob Gilligan, FreeGate Согр.), Питеру Хэверлоку (Peter Haverlock, Nortel 
Networks), C. Ли Генри (S. Lee Henry, Web Publishing, Inc.), Мукешу Кэкеру 
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Глава 1. Введение 


Цель этой книги — помочь программистам разных уровней — от начального до 
среднего — повысить свою квалификацию. Для получения статуса мастера требу- 
ется практический опыт и накопление знаний в конкретной области. Конечно, 
опыт приходит только со временем и практикой, но данная книга существенно 
пополнит багаж ваших знаний. 

Сетевое программирование — это обширная область с большим выбором раз- 
личных технологий для желающих установить связь между несколькими машина- 
ми. Среди них такие простые, как последовательная линия связи, и такие сложные, 
как системная сетевая архитектура (SNA) компании IBM. Но сегодня протоколы 
TCP/IP - наиболее перспективная технология построения сетей. Это обусловлено 
развитием Internet и самого распространенного приложения - Всемирной паути- 
ны (World Wide Web). 


Примечание Вообще-то, Web — не приложение. Но это и не протокол, хотя 
в ней используются и приложения (Web-6payaepw и серверы), 
и протоколы (например, НТТР). Web - это самое популярное сре- 
ди пользователей Internet применение сетевых технологий. 


Однако и до появления Web TCP/IP был распространенным методом созда- 
ния сетей. Это открытый стандарт, и на его основе можно объединять машины раз- 
ных производителей. К концу 90-х годов TCP/IP завоевал лидирующее положе- 
ние среди сетевых технологий, видимо, оно сохранится и в дальнейшем. По этой 
причине в книге рассматриваются TCP/IP и сети, в которых он работает. 

При желании совершенствоваться в сетевом программировании необходимо 
сначала овладеть некоторыми основами, чтобы в полной мере оценить, чем же вам 
предстоит заниматься. Рассмотрим несколько типичных проблем, с которыми стал- 
киваются начинающие. Многие из этих проблем - результат частичного или пол- 
ного непонимания некоторых аспектов протоколов TCP/IP итех API, с помощью 
которых программа использует эти протоколы. Такие проблемы возникают в ре- 
альной жизни и порождают многочисленные вопросы в сетевых конференциях. 


Некоторые термины 


За немногими исключениями, весь материал этой книги, в том числе примеры 
программ, предложен для работы в системах UNIX (32 и 64-разрядных) и систе- 
мах, использующих АРТ Microsoft Windows (Win32 АРТ). Я не экспериментировал 
с 16-разрядными приложениями Windows. Но и для других платформ почти все 
остается применимым. 


He | | [ilii Введение 


Желание сохранить переносимость привело к некоторым несообразностям 
в примерах программ. Tak, программисты, работающие на платформе UNIX, неодоб- 
рительно отнесутся к тому, что для дескрипторов сокетов применяется тип SOCKET 
вместо привычного int. А программисты Windows заметят, что я ограничился толь- 
ко консольными приложениями. Все принятые соглашения описаны в совете 4. 

По той же причине я обычно избегаю системных вызовов read и write для 
сокетов, так как Win32 API ux не поддерживает. Для чтения из сокета или записи 
в него применяются системные вызовы гесу, recvfrom или recvmsg для чтения 
и send, sendto или sendmsg для записи. 

Одним из самых трудных был вопрос о том, следует ли включать в книгу мате- 
риал по протоколу IPv6, который в скором времени должен заменить современ- 
ную версию протокола IP (IPv4). В конце концов, было решено не делать этого. 
Тому есть много причин, в том числе: 


О почти все изложенное в книге справедливо как для IPv4, так и для [Руб; 

О различия, которые все-таки имеются, по большей части сосредоточены в тех 
частях API, которые связаны c адресацией; 

О книга представляет собой квинтэссенцию опыта и знаний современных се- 
тевых программистов, а реального опыта работы с протоколом IPv6 еще не 
накоплено. 


Поэтому, если речь идет просто об IP, то подразумевается IPv4. Там, где упо- 
минается об IPv6, об этом написано. 

И, наконец, я называю восемь бит информации байтом. В сетевом сообществе 
принято называть такую единицу октетом — по историческим причинам. Когда-то 
размер байта зависел от платформы, и не было единого мнения о его точной длине. 
Чтобы избежать неоднозначности, в ранней литературе по сетям и был придуман 
термин октет. Но сегодня все согласны с тем, что длина байта равна восьми битам 
[Kernighan and Pike 1999], так что употребление этого термина можно считать из- 
лишним педантизмом. 


Примечание Однако утверждения о том, что длина байта равна восьми битам, 
время от времени все же вызывают споры в конференциях Usenet: 
«Охужэта нынешняя молодежь! Я в свое время работал на mautu- 
не Баста-6, в которой байт был равен пяти с половиной битам. 
Так что не рассказывайте мне, что в байте всегда восемь бит». 


Путеводитель по книге 


Ниже будут рассмотрены основы АРІ сокетов и архитектура клиент-сервер, 
свойственная приложениям, в которых используется TCP/IP. Это тот фундамент, 
на котором вы станете возводить здание своего мастерства. 

В главе 2 обсуждаются некоторые заблуждения по поводу TCP/IP и сетей во- 
обще. В частности, вы узнаете, в чем разница между протоколами, требующими 
логического соединения, и протоколами, не нуждающимися в нем. Здесь будет рас- 
сказано об [Р-адресации и подсетях (эта концепция часто вызывает недоумение), 
обесклассовой междоменной маршрутизации (Classless Interdomain Routing ~ CIDR) 
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и преобразовании сетевых адресов (Network Address Translation — NAT). Вы уви- 
дите, что ТСР в действительности не гарантирует доставку данных. И нужно быть 
готовым к некорректным действиям как пользователя, так и программы на другом 
конце соединения. Кроме того, приложения будут по-разному работать в глобаль- 
ной (WAN) и локальной (LAN) сетях. 

Следует напомнить, что ТСР - это потоковый протокол, и разъяснить его зна- 
чение для программистов. Вы также узнаете, что ТСР автоматически не обнару- 
живает потерю связи, почему это хорошо и что делать в этой ситуации. 

Вам будет понятно, почему API сокетов всегда следует предпочитать АР] на ос- 
нове интерфейса транспортного уровня (Transport Layer Interface — TLI) и транс- 
портному интерфейсу X/Open (X/Open Transport Interface — XTI). Кроме того, 
я объясню, почему не стоит слишком уж серьезно воспринимать модель OTKDBITO- 
го взаимодействия систем (Open Systems Interconnection – OSI). ТСР - очень эф- 
фективный протокол с отличной производительностью, так что обычно не нужно 
дублировать его функциональность с помощью протокола UDP, 

В главе 2 разработаны каркасы для нескольких видов приложений TCP/IP и на 
их основе построена библиотека часто используемых функций. Каркасы и библио- 
тека позволяют писать приложения, не заботясь о преобразовании адресов, управ- 
лении соединением и т.п. Если каркас готов, то вряд ли следует срезать себе путь, 
например, «зашив» в код адреса и номера портов или опустив проверку ошибок. 

Каркасы и библиотека используются в книге для построения тестов, неболь- 
ших примеров и автономных приложений. Часто требуется всего лишь добавить 
пару строк в один из каркасов, чтобы создать специализированную программу или 
тестовый пример. 

В главе 3 подробно рассмотрены некоторые вопросы, на первый взгляд кажу- 
щиеся тривиальными. Например, что делает операция записи в контексте ТСР. 
Вроде бы все очевидно: записывается в сокет п байт, а ТСР отсылает их на другой 
конец соединения. Но вы увидите, что иногда это происходит не так. В протоколе 
ТСР есть сложный свод правил, определяющих, можно ли посылать данные не- 
медленно и, если да, то сколько. Чтобы создавать устойчивые и эффективные про- 
граммы, необходимо усвоить эти правила и их влияние на приложения. 

To же относится к чтению данных и завершению соединения. Вы изучите эти 
операции и разберетесь, как нужно правильно завершать соединение, чтобы не 
потерять информацию. Здесь будет рассмотрена и операция установления соеди- 
нения connect: когда при ее выполнении возникает тайм-аут и как она использу- 
ется в протоколе UDP. 

Будет рассказано об имеющимся в системе UNIX суперсервере inetd, упро- 
щающим написание сетевых приложений. Вы научитесь пользоваться программой 
tcpmux, которая избавляет от необходимости назначать серверам хорошо извест- 
ные порты. Узнаете, как работает t cpmux, и сможете создать собственную версию 
для систем, где это средство отсутствует. 

Кроме того, здесь подробно обсуждаются такие вопросы, как состояние TIME- 
WAIT, алгоритм Нейгла, выбор размеров буферов и правильное применение оп- 
ции SO, REUSEADDR. Вы поймете, как сделать свои приложения событийно-управляе- 
мыми и создать отдельный таймер для каждого события. Будут описаны некоторые 
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типичные ошибки, которые допускают даже опытные программисты, и приемы 
повышения производительности. 

Наконец, вы познакомитесь с некоторыми языками сценариев, используемы- 
ми при программировании сетей. С их помощью можно легко и быстро создавать 
полезные сетевые утилиты. 

Глава 4 посвящена двум темам. Сначала будет рассмотрено несколько инстру- 
ментальных средств, необходимых каждому сетевому программисту. Показано, как 
использовать утилиту ping для диагностики простейших неисправностей. Затем 
рассказывается о сетевых анализаторах пакетов (sniffer) вообще и программе 
tcpdump в частности. В этой главе дано несколько примеров применения tcpdump 
для диагностики сетевых проблем. С помощью программы traceroute исследу- 
ется маленькая часть Internet. 

Утилита ЕЕ ср, в создании которой принимал участие Майк Myycc (Mike Muuss) — 
автор программы ping, является полезным инструментом для изучения произво- 
дительности сети и влияния на нее тех или иных параметров ТСР. Будут проде- 
монстрированы некоторые методы диагностики. Еще одна бесплатная инструмен- 
тальная программа 1sof необходима в ситуации, когда нужно сопоставить сетевые 
соединения с процессами, которые их открыли. Очень часто 1sof предоставляет 
информацию, получение которой иным способом потребовало бы поистине герои- 
ческих усилий. 

Много внимания уделено утилите netstat и той разнообразной информации, 
которую можно получить с ее помощью, а также программам трассировки систем- 
ных вызовов, таким как ktraceH truss. 

Обсуждение инструментов диагностики сетей завершается построением ути- 
литы для перехвата и отображения датаграмм протокола ICMP (протокол конт- 
роля сообщений в сети Internet). Она не только вносит полезный вклад в ваш набор 
инструментальных средств, но и иллюстрирует использование простых сокетов (raw 
sockets). 

Во второй части главы 4 описаны дополнительные ресурсы для пополнения 
знаний o TCP/IP и сетях. Я познакомлю вас с замечательными книгами Ричарда 
Стивенса, источниками исходных текстов, и собранием документов КЕС (предло- 
жений для обсуждения), размещенных на сервере проблемной группы проектиро- 
вания Internet (Internet Engineering Task Force – IETF) и в конференциях Usenet. 


Архитектура клиент-сервер 


Хотя постоянно говорится о клиентах и серверах, не всегда очевидно, какую 
роль играет конкретная программа. Иногда программы являются равноправными 
участниками обмена информацией, нельзя однозначно утверждать, что одна про- 
грамма обслуживает другую. Однако в случае с TCP/IP различие более четкое. 
Сервер прослушивает порт, чтобы обнаружить входящие ТСР-соединения или 
ООР-датаграммы от одного или нескольких клиентов. С другой стороны, можно 
сказать, что клиент — это тот, кто начинает диалог первым. 

В книге рассмотрены три типичных случая архитектуры клиент-сервер, пока- 
занные на рис. 1.1. В первом случае клиент и сервер работают на одной машине 
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(рис. 1.1а). Это самая простая конфигурация, поскольку нет физической сети. По- 
сылаемые данные, передаются стеку TCP/IP, но не помещаются в выходную оче- 
редь сетевого устройства, а закольцовываются системой и возвращаются обратно 
в стек, но уже в качестве принятых данных. 


Клиент 
Сервер 


а) клиент и сервер на одной машине 


6) клиент и сервер в локальной сети 


Рис. 1.1 
WAN Типичные примеры 
в) клиент и сервер в разных локальных сетях архитектуры клиент-сервер 


На этапе разработки такое размещение клиента и сервера дает определенные 
преимущества, даже если в реальности они будут работать на разных машинах. Во- 
первых, проще оценить производительность обеих программ, так как сетевые за- 
держки исключаются. Во-вторых, этот метод создает идеальную лабораторную 
среду, в которой пакеты не пропадают, не задерживаются и всегда приходят в пра- 
вильном порядке. 


Примечание По крайней мере, почти всегда. Как вы увидите в совете 7, даже 
в этой среде можно создать такую нагрузку, что ОРР-дата- 
граммы будут пропадать. 


И, наконец, разработку вести проще и удобнее, когда можно все отлаживать на 
одной машине. 

Разумеется, даже в условиях промышленной эксплуатации вполне возможно, 
что клиент и сервер будут работать на одном компьютере. В совете 26 описана та- 
кая ситуация. 

Во втором примере конфигурации (рис. 1.16) клиент и сервер работают на раз- 
ных машинах, но в пределах одной локальной сети. Здесь имеет место реальная 
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сеть, но условия все же близки к идеальным. Пакеты редко теряются и практичес- 
ки всегда приходят в правильном порядке. Такая ситуация очень часто встречает- 
ся на практике. Причем некоторые приложения предназначены для работы только 
в такой среде. 

Типичный пример — сервер печати. В небольшой локальной сети может быть 
только один такой сервер, обслуживающий несколько машин. Одна машина (или 
сетевое программное обеспечение на базе TCP/IP, встроенное в принтер) высту- 
пает в роли сервера, который принимает запросы на печать от клиентов на других 
машинах и ставит их в очередь к принтеру. 

В третьем примере (рис. 1.18) клиент и сервер работают на разных KOMID- 
ютерах, связанных глобальной сетью. Этой сетью может быть Internet или кор- 
поративная Intranet, но главное — приложения уже не находятся внутри одной 
локальной сети, так что на пути [Р-датаграмм есть, по крайней мере, один мар- 
шрутизатор. 

Такое окружение может быть более «враждебным», чем в первых двух случа- 
ях. По мере роста трафика в глобальной сети начинают переполняться очереди, 
в которых маршрутизатор временно хранит поступающие пакеты, пока не отпра- 
вит их адресату. А когда в очереди больше нет места, маршрутизатор отбрасыва- 
ет пакеты. В результате клиент должен передавать пакеты повторно, что приво- 
дит к появлению дубликатов и доставке пакетов в неправильном порядке. Эти 
проблемы возникают довольно часто, как вы увидите в совете 38. 

О различиях между локальными и глобальными сетями будет рассказано 
в совете 12. 


Элементы АРІ сокетов 


В этом разделе кратко рассмотрены основы АРІ сокетов и построены простейшие 
клиентское и серверное приложения. Хотя эти приложения очень схематичны, на их 
примере проиллюстрированы важнейшие характеристики клиента и сервера ТСР. 

Начнем с вызовов API, необходимых для простого клиента. Ha рис. 1.2 показа- 
ны функции, применяемые в любом клиенте. Адрес удаленного хоста задается 
с помощью структуры sockadár, in, которая передается функции connect. 

Первое, что вы должны сделать, — это получить сокет для логического соеди- 
нения. Для этого предназначен системный вызов socket. 


#1пс1аае «sys/socket.h» /* UNIX */ 
d$include «winsock2.h-» /* Windows */ 


SOCKET socket( int domain, int type, int protocol ); 


Возвращаемое значение: дескриптор сокета в случае успеха; -1 (UNIX) или 
INVALID SOCKET (Windows) — ошибка. 


API сокетов He зависит OT протокола и может поддерживать разные адресные 
домены. Параметр domain – это константа, указывающая, какой домен нужен CO- 
кету. 


Элементы АР! сокетов ЕЕ | | 21 


Чаще используются домены АР_ТМЕТ (то есть Internet) и AF LOCAL (или 
AF UNIX). В книге рассматривается только домен AF. INET. Домен AF. LOCAL при- 
меняется для межпроцессного взаимодействия (ТРС) на одной и той же машине. 


Примечание Существуют разногласия по поводу того, следует ли обозначать 
константы доменов АЕ_* или РЕ_*. Сторонники РЕ_* указывают 
на их происхождение от уже устаревших вариантов вызова 
socket в системах 4.1c/2.8/2.9BSSD. И, кроме того, они считают, 
umo PF означает protocol family (семейство протоколов). Сторон- 
ники же AF. * говорят, что в коде ядра, относящемся к реализации 
сокетов, параметр domain сравнивается именно с константами 
AF *. Но, поскольку оба набора констант определены одинаково — 
в действительности одни константы просто выражаются через 
другие, — на практике можно употреблять оба варианта. 


С помощью параметра type задается тип создаваемого сокета. Чаще встреча- 
ются следующие значения (а в этой книге только такие) сокетов: 


О SOCK, STREAM - обеспечивают надежный 
дуплексный протокол на основе установ- 
ления логического соединения. Если гово- 
рится о семействе протоколов TCP/IP то 
это ТСР; 

О SOCK. DGRAM — обеспечивают ненадежный 
сервис доставки датаграмм. В рамках ГСР/ 


IP это будет протокол UDP; 


О SOCK, RAW —предоставляют доступ к HEKO- 
торым датаграммам на уровне протокола 
IP. Они используются в особых случаях, 


например для просмотра всех ІСМР-сооб- Рис. 1.2. Основные вызовы 
щений. API сокетов для клиентов 


Sockaddr, iní) 


Парная 
программа 


Параметр protocol показывает, какой про- 
токол следует использовать с данным сокетом. В контексте TCP/IP он обычно не- 
явно определяется типом сокета, поэтому в качестве значения задают 0. Иног- 
да, например в случае простых (raw) сокетов, имеется несколько возможных 
протоколов, так что нужный необходимо задавать явно. Об этом будет рассказано 
в совете 40. 

Для самого простого ТСР-клиента потребуется еще один вызов АР] сокетов, 
обеспечивающий установление соединения: 


#include «sys/socket.h» /* UNIX */ 
#include «winsock2.h-» /* Windows */ 


int connect( SOCKET s, const struct sockaddr *peer, int peer len ); 


Возвращаемое значение: 0 — нормально, —1 (UNIX) или не 0 (Windows) — 
ошибка. 


Введение 


Параметр s — это дескриптор сокета, который вернул системный вызов socket. 
Параметр peer указывает на структуру, в которой хранится адрес удаленного хо- 
ста и некоторая дополнительная информация. Для домена AF, INET - это структу- 
ра типа sockaddr_in. Ниже вы увидите, как она заполняется. Параметр peer, len 
содержит размер структуры в байтах, на которую указывает peer. 

После установления соединения можно передавать данные. B OC UNIX вы 
должны обратиться к системным вызовам read и write и передать им дескриптор 
сокета точно так же, как передали бы дескриптор открытого файла. Увы, как уже 
говорилось, B Windows эти системные вызовы не поддерживают семантику соке- 
тов, поэтому приходится пользоваться вызовами гесу и зепа. Они отличаются от 
read и write только наличием дополнительного параметра. 


#include «sys/socket.h» /* UNIX */ 
#include «winsock2.h» /* Windows */ 
int recv( SOCKET s, void *buf, size t len, int flags ); 


int send( SOCKET s, const void *buf, size t len, int flags ); 


Возвращаемое значение: число принятых или переданных байтов B случае yc- 
пеха или —1 в случае ошибки. 


Параметры s, БиЁи len означают то же, что и для вызовов read H write. 3Ha- 
чение параметра flags в основном зависит от системы, но и UNIX, и Windows 
поддерживают следующие флаги: 


О MSG, OOB - следует послать или принять срочные данные; 

О MSG, PEEK - используется для просмотра поступивших данных без их удале- 
ния из приемного буфера. После возврата из системного вызова данныееще 
могут быть получены при последующем вызове read или recv; 

О MSG, DONTROUTE – сообщает ядру, что не надо выполнять обычный алгоритм 
маршрутизации. Как правило, используется программами маршрутизации 
или для диагностических целей. 


При работе с протоколом ТСР вам ничего больше не понадобится. Но при ра- 
боте с UDP нужны еще системные вызовы recvfromH sendto. Они очень похожи 
Ha гесу и send, но позволяют при отправке датаграммы задать адрес назначения, 
а при приеме – получить адрес источника. 


finclude «sys/socket.h» /* UNIX */ 
finclude «winsock2.h» /* Windows */ 


int recvfrom( SOCKET s, void *buf, size t len, int flags, 
struct sockaddr *from, int *fromlen ); 


int sendto( SOCKET s, const void *buf, size t len, int flags, 
const struct sockaddr *to, int tolen); 


Возвращаемое значение: число принятых или переданных байтов B случае yc- 
пеха или —1 при ошибке. 


Элементы АР! сокетов 


Первые четыре параметра — s, buf, len и flags — такие же, как в вызовах 
recv и send. Параметр from в вызове recvfrom указывает на структуру, B KOTO- 
рую ядро помещает адрес источника пришедшей датаграммы. Длина этого адреса 
хранится в целом числе, на которое указывает параметр Егот1еп. Обратите вни- 
мание, что fromlen — это указатель на целое. 

Аналогично параметр to в вызове sendto указывает на адрес структуры, co- 
держащей адреса назначения датаграммы, а параметр tolen - длина этого адреса. 
Заметьте, что tO — это целое, a не указатель. 

В листинге 1.1 приведен пример простого ТСР-клиента. 


Листинг 1.1. Простейший ТСР-клиент 


simplec.c 


1 $£include <sys/types.h> 

2 #1пс1аае «sys/socket.h» 

3 £finclude «netinet/in.h» 

4 finclude «arpa/inet.h» 

5 $£include <stdio.h> 

6 int main( void ) 

7 { 

8 struct sockaddr in peer; 

9 int s; 

10 int re; 

11 char buf£[ 1 ]; 

12 peer.sin, family = AF, INET; 

13 peer.sin port - htons( 7500 ); 

14 peer.sin addr.s addr = inet addr( "127.0.0.1" ); 
15 5 = Socket( AF INET, SOCK STREAM, 0 ); 
16 if (8s «0) 

17 ( 

18 perror( "ошибка вызова Socket" ); 
19 exit( 1 ); 

20 ) 

21 rc - connect( s, ( struct sockaddr * )&peer, sizeof( peer ) ); 
22 if ( rc ) 

23 ( 

24 perror( "ошибка вызова connect" ); 
25 exit( 1 ); 

26 ) 


rc - send( s, "1", 1, 0 ); 
if ( rc <= 0 ) 


perror( "ошибка вызова send" ); 
exit( 1 5 
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35 perror( "ошибка вызова recv" ); 
36 else 

37 printf( "€cWMn", buf[ 0 ] }; 

38 exit( O ); 

39 ) 


simplec.c 


Клиент в листинге 1.1 написан как UNIX-nporpaMMa, чтобы не было сложнос- 
тей, связанных с переносимостью и УЛп4о\з-функцией WSAStartup. В совете 4 
сказано, что в основном эти сложности можно скрыть в заголовочном файле, но 
сначала надо подготовить некоторые механизмы. Пока ограничимся более простой 
моделью UNIX. 


Подготовка адреса сервера 


12-14 Заполняем структуру sockaddr, in, записывая в ее поля номер порта 
(7500) и адрес. 127.0.0.1 — это возвратный адрес, который означает, что 
сервер находится на той же машине, что и клиент. 


Получение сокета и соединение с сервером 


15-20 Получаем сокет типа SOCK_STREAM. Как было отмечено выше, протокол 
ТСР, будучи потоковым, требует именно такого сокета. 

21-26 Устанавливаем соединение с сервером, обращаясь к системному вызо- 
ву connect. Этот вызов нужен, чтобы сообщить ядру адрес сервера. 


Отправка и получение одного байта 


27-38 Сначала посылаем один байт серверу, затем читаем из сокета один байт 
и записываем полученный байт в стандартный вывод и завершаем сеанс. 


Прежде чем тестировать клиента, необходим сервер. Вызовы API сокетов для 
сервера немного иные, чем для клиента. Они показаны на рис. 1.3. 

Сервер должен быть готов к установлению соединений с клиентами. Для это- 
го он обязан прослушивать известный ему порт с помощью системного вызова 
listen. Но предварительно необходимо привязать адрес интерфейса и номер 
порта к прослушивающему сокету. Для этого предназначен вызов bind: 


finclude «sys/socket.h» /* UNIX */ 
dtinclude «winsock2.h-» /* Windows */ 


int bind( SOCKET s, const struct sockaddr *name, int namelen ); 


Возвращаемое значение: 0 — нормально, –1 (UNIX) или SOCKET, ERROR (Win- 
dows) — ошибка. 


Параметр s – это дескриптор прослушивающего сокета. C помощью парамет- 
ров name и пате1еп передаются порт и сетевой интерфейс, которые нужно про- 
слушивать. Обычно в качестве адреса задается константа INADDR, ANY. Это озна- 
чает, что будет принято соединение, запрашиваемое по любому интерфейсу. Если 
хосту с несколькими сетевыми адресами нужно принимать соединения только по 
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одному интерфейсу, то следует указать ГР-адрес этого интерфейса. Как обычно, 
namelen - длина структуры sockaddr, in. 

После привязки локального адреса к сокету нужно перевести сокет в режим 
прослушивания входящих соединений с помощью системного вызова listen, на- 
значение которого часто не понимают. Его единственная задача — пометить сокет 
как прослушивающий. Когда хосту поступает запрос на установление соединения, 
ядро ищет в списке прослушивающих сокетов тот, для которого адрес назначения 
и номер порта соответствуют указанным в запросе. 


f&include «sys/socket.h» /* UNIX */ 
$include «winsock2.h» /* Windows */ 


int listen( SOCKET s, int backlog ); 


Возвращаемое значение: 0 — нормально, —1 (UNIX) или SOCKET, ERROR (Win- 
dows) — ошибка. 


Параметр s — это дескриптор сокета, кото- 
рый нужно перевести в режим прослушивания. 
Параметр backlog — это максимальное число 
ожидающих, но еще не принятых соединений. 
Следует отметить, что это не максимальное 
число одновременных соединений с данным 
портом, а лишь максимальное число частично 
установленных соединений, ожидающих в оче- 
реди, пока приложение их примет (описание си- 
стемного вызова accept дано ниже). 

Традиционно значение параметра backlog 
не более пяти соединений, но в современных 
реализациях, которые должны поддерживать 
приложения с высокой нагрузкой, например, 
Web-cepBepa, оно может быть намного больше. 
Поэтому, чтобы выяснить его истинное значе- 
ние, необходимо изучить документацию по кон- 
кретной системе. Если задать значение, большее 
максимально допустимого, то система умень- 
шит его, не сообщив об ошибке. 

И последний вызов, который будет здесь Рис. 1.3, Основные вызовы 
рассмотрен, - это accept. Он служит для при- АР! сокетов для сервера 
ема соединения, ожидающего во входной оче- 
реди. После того как соединение принято, его можно использовать для передачи 
данных, например, с помощью вызовов recv и send. В случае успеха accept воз- 
вращает дескриптор нового сокета, по которому и будет происходить обмен дан- 
ными. Номер локального порта для этого сокета такой же, как и для прослушивающе- 
TO сокета. Адрес интерфейса, на который поступил запрос о соединении, называется 
локальным. Адрес и номер порта клиента считаются удаленными. 


зоскаааг_1п{} 


-— Локально 


sockaddr, in() 


рери Парная 
программа 
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Обратите внимание, что оба сокета имеют один и тот же номер локального 
порта. Это нормально, поскольку ТСР-соединение полностью определяется че- 
тырьмя параметрами — локальным адресом, локальным портом, удаленным адре- 
сом и удаленным портом. Поскольку удаленные адрес и порт для этих двух соке- 
тов различны, то ядро может отличить их друг от друга. 


#include «sys/socket.h» /* UNIX */ 
#include «winsock2.h» /* Windows */ 


int accept( SOCKET s, struct sockaddr *addr, int *addrlen ); 


Возвращаемое значение: 0 — нормально, —1 (UNIX) или INVALID SOCKET 
(Windows) – ошибка. 


Параметр s ~ это дескриптор прослушивающего сокета. Как показано на рис. 1.3, 
accept возвращает адрес приложения на другом конце соединения в структуре 
sockaddr, in, на которую указывает параметр addr. Целому числу, на которое 
указывает параметр аааг1еп, ядро присваивает значение, равное длине этой струк- 
туры. Часто нет необходимости знать адрес клиентского приложения, поэтому 
в качестве addr и addrlen будет передаваться NULL. 

В листинге 1.2 приведен простейший сервер. Эта программа также очень схе- 
матична, поскольку ее назначение — продемонстрировать структуру сервера и эле- 
ментарные вызовы АРІ сокетов, которые обязан выполнить любой сервер. Обра- 
тите внимание, что, как и в случае с клиентом на рис. 1.2, сервер следует потоку 
управления, показанному на рис. 1.3. 


Листинг 1.2. Простой TCP-cepBep 


simples.c 


1 d$include <sys/types.h> 

2 $include «sys/socket.h» 

3 include «netinet/in.h» 

4 #include <stdio.h> 

5 int main( void ) 

6 { 

7 struct sockaddr, in local; 

8 int s; 

9 int s1; 

10 int rc; 

11 char buf[ 1 |; 

12 local.sin family = AF INET; 

13 local.sin port - htons( 7500 ); 

14 1оса1.ѕіп addr.s addr = htonl( INADDR ANY ); 
15 S = Ssocket( AF INET, SOCK STREAM, O0 ); 
16 if (s sr ТЕ. 

17 { 

18 perror( "ошибка вызова socket" ); 
19 exit( 1 ); 


Элементы АРІ сокетов 


127 


20 } 

21 rc = bind( s, ( struct sockaddr * )&local, sizeof( local ) }; 
22 if (rc «00 ) 

23 ( 

24 perror( "ошибка вызова bind" ); 
25 exit( 1 ); 

26 ) 

27 rc = listen( s, 5 ); 

28 if (rce) 

29 { 

30 perror( "ошибка вызова listen" }; 
31 exit( 1 ); 

32 } 


33 51 = accept( в, NULL, NULL ); 
34 if ( s1 < 0) 


35 { 

36 perror( "ошибка вызова accept" ); 
37 exit( 1 ); 

38 ) 

39 rc = recv( sl, buf, 1, 0 ); 

40 if (rec <= 0) 

41 ( 

42 perror( "ошибка вызова recv" ); 
43 exit( 1 ); 

44 } 


45 ЕИБ "%c\n", buf{ 0 ] ); 
46 rc = send( s1, "2", 1, 0 ); 
47 if ( re <= 0 ) 


48 perror( "ошибка вызова send" ); 
49 exit( 0 ); 
50 ) 


simples.c 


Заполнение адресной структуры и получение сокета 

12-20 Заполняем структуру sockaddr. іп, записывая в ее поля известные ад- 
рес и номер порта, получаем сокет типа SOCK, STREAM, который и будет 
прослушивающим. 


Привязка известного порта и вызов listen 


21-32 Привязываем известные порт и адрес, записанные в структуру local, 
к полученному сокету. Затем вызываем listen, чтобы пометить сокет 
как прослушивающий. 


Принятие соединения 


33-39 Вызываем accept для приема новых соединений. Вызов accept бло- 
кирует выполнение программы до тех пор, пока не поступит запрос 
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на соединение, после чего возвращает новый сокет для этого соеди- 
нения. 


Обмен данными 

39-49 Сначала читаем и печатаем байт со значением 1, полученный от клиента. 
Затем посылаем один байт со значением 2 назад клиенту и завершаем 
программу. 


Теперь можно протестировать клиент и сервер, запустив сервер в одном окне, 
а клиент — в другом. Обратите внимание, что сервер должен быть запущен пер- 
вым, иначе клиент аварийно завершится с сообщением Connection refused 
(В соединении отказано). 


bsd: $ simplec 
ошибка вызова connect: Connection refused 
bsd: $ 


Ошибка произошла потому, что при попытке клиента установить соединение 
не было сервера, прослушивающего порт 7500. 

Теперь следует поступить правильно, то есть запустить сервер до запуска кли- 
ента: 


bsd: $ simples bsd: $ simplec 


1 2 
bsd: $ bsd: $ 
Резюме 


В этой главе приведен краткий обзор последующих глав и рассмотрены эле- 
менты API сокетов. Теперь можно перейти к более сложному материалу. 


Глава 2. Основы 


Совет 1. Различайте протоколы, 
требующие и не требующие 
установления логического соединения 


Один из фундаментальных вопросов сетевого программирования — это раз- 
личие между протоколами, требующими установления логического соединения 
(connection-oriented protocols), и протоколами, не требующими этого (connectionless 
protocols). Хотя ничего сложного в таком делении нет, но начинающие их часто пу- 
тают. Частично проблема кроется в выборе слов. Очевидно, что два компьютера дол- 
жны быть как-то «соединены», если необходимо наладить обмен данными между 
ними. Тогда что означает «отсутствие логического соединения»? 

О наличии и отсутствии логического соединения говорят применительно к про- 
токолам. Иными словами, речь идет о способе передачи данных по физическому 
носителю, а не о самом физическом носителе. Протоколы, требующие и не требу- 
ющие логического соединения, могут одновременно разделять общий физический 
носитель; на практике обычно так и бывает. 

Ноесли это деление не имеет ничего общего с физическим носителем, по кото- 
рому передаются данные, то что же лежит в его основе? Главное различие в том, 
что в протоколах, не требующих соединения, каждый пакет передается независи- 
мо от остальных. Тогда как протоколы, устанавливающие соединение, поддержи- 
вают информацию о состоянии, которая позволяет следить за последовательнос- 
тью пакетов. 

При работе с протоколом, не требующим соединения, каждый пакет, именуемый 
датаграммой, адресуется и посылается приложением индивидуально (совет 30). 
С точки зрения протокола каждая датаграмма — это независимая единица, не имею- 
щая ничего общего с другими датаграммами, которыми обмениваются приложения. 


Примечание Это не означает, что датаграммы независимы с точки зрения 
приложения. Если приложение реализует нечто более сложное, 
чем простой протокол запрос-ответ (клиент посылает серверу 
одиночный запрос и ожидает одиночного ответа на него), то, 
скорее всего, придется отслеживать состояние. Но суть в том, 
что приложение, а не протокол, отвечает за поддержание ин- 
формации о состоянии. Пример сервера, который не требует 
установления соединения, но следит за последовательностью 
датаграмм, приведен в листинге 3.6. 


ТТ Основы 


Обычно это означает, что клиент и сервер не ведут сложного диалога, — кли- 
ент посылает запрос, а сервер отвечает на него. Если позже клиент посылает но- 
вый запрос, то с точки зрения протокола это новая транзакция, не связанная 
с предыдущей. 

Кроме того, протокол не обязательно надежен, то есть сеть предпримет все воз- 
можное для доставки каждой датаграммы, но нет гарантий, что ни одна не будет 
потеряна, задержана или доставлена не в том порядке. 

С другой стороны, протоколы, требующие установления соединения, самосто- 
ятельно отслеживают состояние пакетов, поэтому они используются в приложе- 
ниях, ведущих развитый диалог. Сохраняемая информация о состоянии позволя- 
ет протоколу обеспечить надежную доставку. Например, отправитель запоминает, 
когда и какие данные послал, но они еще не подтверждены. Если подтверждение 
не приходит в течение определенного времени, отправитель повторяет передачу. 
Получатель запоминает, какие данные уже принял, и отбрасывает пакеты-дубли- 
каты. Если пакет поступает не в порядке очередности, то получатель может «при- 
держать» его, пока не придут логически предшествующие пакеты. 

У типичного протокола, требующего наличия соединения, есть три фазы. Сна- 
чала устанавливается соединение между двумя приложениями. Затем происходит 
обмен данными. И, наконец, когда оба приложения завершили обмен данными, 
соединение разрывается. 

Обычно такой протокол сравнивают с телефонным разговором, а протокол, 
не требующий соединения, — с отправкой письма. Каждое письмо запечатывается 
в отдельный конверт, на котором пишется адрес. При этом все письма оказывают- 
ся самостоятельными сущностями. Каждое письмо обрабатывается на почте неза- 
висимо от других посланий двух данных корреспондентов. Почта не отслеживает 
историю переписки, то есть состояние последовательности писем. Кроме того, не 
гарантируется, что письма не затеряются, не задержатся и будут доставлены в пра- 
вильном порядке. Это соответствует отправке датаграммы протоколом, He требу- 
ющим установления соединения. 


Примечание Хаверлок [Haverlock 2000] отмечает, что более правильная ана- 
логия — не письмо, а почтовая открытка, так как письмо с не- 
правильным адресом возвращается отправителю, а почтовая 
открытка — никогда (как и в типичном протоколе, не требую- 
щем наличия соединения). 


А теперь посмотрим, что происходит, когда вы не посылаете письмо другу, 
а звоните по телефону. Для начала набираете его номер. Друг отвечает. Некоторое 
время вы разговариваете, потом прощаетесь и вешаете трубки. Так же обстоит дело 
и в протоколе, требующем соединения. В ходе процедуры установления соедине- 
ния одна из сторон связывается с другой, стороны обмениваются «приветствия- 
ми» (на этом этапе они «договариваются» о тех параметрах и соглашениях, кото- 
рым будут следовать далее), и соединение вступает в фазу обмена данными. 

Во время телефонного разговора звонящий знает своего собеседника. И перед 
каждой фразой не нужно снова набирать номер телефона — соединение установлено. 


Необходимость логического соединения 


Аналогично в фазе передачи данных протокола, требующего наличия соединения, 
не надо передавать свой адрес или адрес другой стороны. Эти адреса — часть ин- 
формации о состоянии, хранящейся вместе с логическим соединением. Остается 
только посылать данные, не заботясь ни об адресации, ни о других деталях, свя- 
занных с протоколом. 

Как и в разговоре по телефону, каждая сторона, заканчивая передачу данных, 
информирует об этом собеседника. Когда обе стороны договорились о завершении, 
они выполняют строго определенную процедуру разрыва соединения. 


Примечание Хотя указанная аналогия полезна, но она все же не точна. В те- 
лефонной сети устанавливается физическое соединение. А при- 
водимое «соединение» целиком умозрительно, оно состоит лишь 
из хранящейся на обоих концах информации о состоянии. Что- 
бы должным образом понять это, подумайте, что произойдет, 
если хост на одном конце соединения аварийно остановится 
и начнет перезагружаться. Соединение все еще есть? По отно- 
шению к перезагрузившемуся хосту — конечно, нет. Все соедине- 
ния установлены в его «прошлой жизни». Но для его бывшего «co- 
беседника» соединение по-прежнему существует, так как у него 
все еще хранится информация о состоянии, и не произошло ни- 
чего такого, что сделало бы ее недействительной. 


В связи с многочисленными недостатками протоколов, не требующих соеди- 
нения, возникает закономерный вопрос: зачем вообще нужен такой вид протоко- 
лов? Позже вы узнаете, что часто встречаются ситуации, когда для создания 
приложения использование именно такого протокола оправдано. Например, 
протокол без соединения может легко поддерживать связь одного хоста со мно- 
гими и наоборот. Между тем протоколы, устанавливающие соединение, должны 
обычно организовать по одному соединению между каждой парой хостов. Важно 
то, что протоколы, не требующие наличия соединения, — это 
фундамент, на котором строятся более сложные протоколы. 
Рассмотрим набор протоколов TCP/IP. В совете 14 roso- 
purca, что TCP/IP - это четырехуровневый стек протоко- 
лов (puc. 2.1) DT 

Внизу стека находится интерфейсный уровень, который 
связан непосредственно с аппаратурой. Наверху располагают- 
ся такие приложения, как telnet, ftp и другие стандартные Рис. 2.1 
и пользовательские программы. Как видно из рис. 2.1, ТСР Упрощенное 
и ОБР построены поверх IP. Следовательно, IP – это фунда- представление 
мент, на котором возведено все здание TCP/IP. Но IP предо- стека протоколов 
ставляет лишь ненадежный сервис, не требующий установле- TCP/IP 
ния соединения. Этот протокол принимает пакеты C выше- 
расположенных уровней, обертывает их в ІР-пакет и направляет подходящему 
аппаратному интерфейсу для отправки в сеть. Послав пакет, IP, как и все протоко- 
лы, не устанавливающие соединения, не сохраняет информацию о нем. 


Основы 


В этой простоте и заключается главное достоинство протокола IP. Поскольку 
IP не делает никаких предположений о физической среде передачи данных, OH 
может работать с любым носителем, способным передавать пакеты. Так, IP рабо- 
тает на простых последовательных линиях связи, в локальных сетях на базе техно- 
логий Ethernet и Token Ring, в глобальных сетях на основе протоколов Х.25 и АТМ 
(Asynchronous Transfer Mode — асинхронный режим передачи), в беспроводных 
сетях CDPD (Cellular Digital Packet Data — сотовая система передачи пакетов циф- 
ровых данных) и во многих других средах. Хотя эти технологии принципиально 
различны, с точки зрения IP они не отличаются друг от друга, поскольку способ- 
ны передавать пакеты. Отсюда следует важнейший вывод: раз [Р может работать 
в любой сети с коммутацией пакетов, То это относится и ко всему набору протоко- 
лов TCP/IP. 

А теперь посмотрим, как протокол ТСР пользуется этим простым сервисом, 
чтобы организовать надежный сервис с поддержкой логических соединений. По- 
скольку ТСР-пакеты (они называются сегментами) посылаются в составе ІР-да- 
TarpaMM, у ТСР пет информации, дойдут ли они до адреса, не говоря о возможно- 
сти искажения данных или о доставке в правильном порядке. Чтобы обеспечить 
надежность, ТСР добавляет к базовому [Р-сервису три параметра. Во-первых, в TCP- 
сегмент включена контрольная сумма содержащихся в нем данных. Это позволяет 
в пункте назначения убедиться, что переданные данные не повреждены сетью во 
время транспортировки. Во-вторых, ТСР присваивает каждому байту порядковый 
номер, так что даже если данные прибывают в пункт назначения не в том порядке, 
в котором были отправлены, то получатель сможет собрать из них исходное сооб- 
щение. 


Примечание Разумеется, ТСР не передает порядковый номер вместе с каж- 
дым байтом. Просто в заголовке каждого ТСР-сегмента хра- 
нится порядковый номер первого байта. Тогда порядковые номе- 
ра остальных байтов можно вычислить. 


В-третьих, в ТСР имеется механизм подтверждения и повторной передачи, 
который гарантирует, что каждый сегмент когда-то будет доставлен. 

Из трех упомянутых выше добавлений механизм подтверждения/повторной 
передачи самый сложный, поэтому рассмотрим подробнее его работу. 


Примечание Здесь опускаются некоторые детали. Это обсуждение поверх- 
ностно затрагивает многие тонкости протокола ТСР и их при- 
менение для обеспечения надежного и отказоустойчивого транс- 
портного механизма. Более доступное и подробное изложение вы 
можете найти в ВЕС 793 [Postel 19816] и RFC 1122 [Braden 
1989], в книге [Stevens 1994], В RFC 813 [Clark 1982] обсужда- 
ется механизм окон и подтверждений ТСР. 


На каждом конце ТСР-соединения поддерживается окно приема, представляю- 
щее собой диапазон порядковых номеров байтов, который получатель готов принять 
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от отправителя. Наименьшее значение, соответствующее левому краю окна, — это 
порядковый номер следующего ожидаемого байта. Наибольшее значение, соответ- 
ствующее правому краю окна, — это порядковый номер последнего байта, для ко- 
торого y ТСР есть место в буфере. Использование окна приема (вместо посылки 
только номера следующего ожидаемого байта) повышает надежность протокола 
за счет предоставления средств управления потоком. Механизм управления пото- 
ком предотвращает переполнение буфера ТСР. 

Когда прибывает ТСР-сегмент, все байты, порядковые номера которых оказы- 
ваются вне окна приема, отбрасываются. Это касается как ранее принятых данных 
(с порядковым номерами левее окна приема), так и данных, для которых нет места 
в буфере (с порядковым номерами правее окна приема). Если первый допустимый 
байт в сегменте не является следующим ожидаемым, значит, сегмент прибыл не по 
порядку. В большинстве реализаций ТСР такой сегмент помещается в очередь 
и находится в ней, пока не придут пропущенные данные. Если же номер первого 
допустимого байта совпадает со следующим ожидаемым, то данные становятся 
доступными для приложения, а порядковый номер следующего ожидаемого байта 
увеличивается на число байтов в сегменте. В этом случае считается, что окно сдви- 
гается вправо на число принятых байтов. Наконец, ТСР посылает отправителю 
подтверждение (сегмент АСК), содержащее порядковый номер следующего ожи- 
даемого байта. 

Например, на рис. 2.2а окно приема обведено пунктиром. Вы видите, что по- 
рядковый номер следующего ожидаемого байта равен 4, и ТСР готов принять 
9 байт (с 4 по 12). На рис. 2.26 показано окно приема после поступления байтов 
с номерами 4-7. Окно сдвинулось вправо на четыре номера, а в сегменте АСК, 
который пошлет ТСР, номер следующего ожидаемого байта будет равен 8. 


Окно приема 
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Рис. 2.2. Окно приема ТСР 


Теперь рассмотрим эту же ситуацию с точки зрения протокола ТСР на посыла- 
ющем конце. Помимо окна приема, ТСР поддерживает также окно передачи, разде- 
ленное на две части. В одной из них расположены байты, которые уже отосланы, но 
еще не подтверждены, а в другой — байты, которые еще не отправлены. Предполага- 
ется, что на байты 1—3 уже пришло подтверждение, поэтому Ha рис. 2.3a изображено 
окно Передачи, соответствующее окну приема на рис. 2.2а. На рис. 2.36 вы видите 
окно передачи после пересылки байтов 4-7, но до прихода подтверждения. ТСР еще 
может послать байты 8—12, не дожидаясь подтверждения от получателя. После oT- 
правки байтов 4—7 ТСР начинает отсчет тайм-аута ретрансмиссии (retransmission 
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timeout — КТО). Если до срабатывания таймера не пришло подтверждение на все 
четыре байта, ТСР считает, что они потерялись, и посылает их повторно. 


Примечание Поскольку в многих реализациях не происходит отслеживания 
того, какие байты были посланы в конкретном сегменте, может 
случиться, что повторно переданный сегмент содержит боль- 
ше байтов, чем первоначальный. Например, если байты 8 и 9 
были посланы до срабатывания КТО-таймера, то такие реали- 
зации повторно передадут байты с 4 по 9. 


Обратите внимание, что срабатывание КТО-таймера не означает, что исходные 
данные не дошли до получателя. Например, может потеряться АСК-сегмент 
с подтверждением или исходный сегмент задержаться в сети на время, большее чем 
тайм-аут ретрансмиссии. Но ничего страшного в этом нет, так как если первона- 
чально отправленные данные все-таки прибудут, то повторно переданные окажут- 
ся вне окна приема ТСР и будут отброшены. 

После получения подтверждения на байты 4—7 передающий ТСР «забывает» 
про них и сдвигает окно передачи вправо, как показано на рис. 2.38. 


Окно приема 
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Рис. 2.3. Окно передачи ТСР 


ТСР обеспечивает прикладного программиста надежным протоколом, требу- 
ющим установления логических соединений. О таком протоколе рассказывается 
в совете 9. 

С другой стороны, UDP предоставляет программисту ненадежный сервис, He 
требующий соединения. Фактически UDP добавляет лишь два параметра к про- 
токолу IP, поверх которого он построен. Во-первых, необязательную контрольную 
сумму для обнаружения искаженных данных. Хотя у самого протокола [Р тоже 
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есть контрольная сумма, но вычисляется она только для заголовка ІР-пакета, по- 
этому ТСР и UDP также включают контрольные суммы для защиты собственных 
заголовков и данных. Во-вторых, UDP добавляет к IP понятие порта. 

Для отправки [Р-датаграммы конкретному хосту используются ІР-адреса, то 
есть адреса, которые обычно приводятся в стандартной десятичной нотации Internet 
(совет 2). Но по прибытии на хост назначения датаграмму еще необходимо доста- 
вить нужному приложению. Например, один UDP-raker может быть предназна- 
чен для сервиса эхо-контроля, а другой — для сервиса «время дня». Порты как раз 
и дают способ направления данных нужному приложению (этот процесс называ- 
ют демультиплексированием). С каждым ТСР и UDP-cokeroM ассоциирован Ho- 
мер порта. Приложение может явно указать этот номер путем обращения к сис- 
темному вызову bind или поручить операционной системе выбор порта. Когда 
пакет прибывает, ядро «ищет» в списке сокетов тот, который ассоциирован с про- 
TOKOJIOM, парой адресов и парой номеров портов, указанных в пакете. Если сокет 
найден, то данные обрабатываются соответствующим протоколом (в примерах 
ТСР или UDP) и передаются тем приложениям, которые этот сокет открыли. 


Примечание Если сокет открыт несколькими процессами или потоками 
(thread), то данные может считывать только один из них, 
остальным они будут недоступны. 


Возвращаясь к аналогии с телефонными переговорами и письмами, можно ска- 
зать, что сетевой адрес в ТСР-соединении подобен номеру телефона офисной АТС, 
а номер порта - это добавочный номер конкретного телефона в офисе. Точно так 
же ПОР-адрес можно представить как адрес многоквартирного дома, а номер пор- 
та — как отдельный почтовый ящик в его подъезде. 


Резюме 


В этом разделе обсуждены различия между протоколами, которые требуют 
и не требуют установления логического соединения. Вы узнали, что ненадежные 
протоколы, в которых происходит обмен датаграммами без установления соеди- 
нения, — это фундамент, на котором строятся надежные протоколы на базе соеди- 
нений. Попутно было кратко изложено, как надежный протокол ТСР строится на 
основе ненадежного протокола [Р. 

Также отмечалось, что понятие «соединение» в ТСР носит умозрительный ха- 
рактер. Оно состоит из хранящейся информации о состоянии на обоих концах; ни- 
какого «физического» соединения, как при телефонном разговоре, не существует. 


Совет 2. Выясните, что такое подсети и CIDR 


Длина ІР-адреса (в версии IPv4) составляет 32 бита. Адреса принято записы- 
вать в десятичной нотации — каждый из четырех байт представляется одним деся- 
тичным числом, которые отделяются друг от друга точками. Так, адрес 0х11345678 
записывается в виде 17.52.86.120. При записи адресов нужно учитывать, что в не- 
которых реализациях ТСР/ТР принято стандартное для языка С соглашение о том, 
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что числа, начинающиеся с нуля, записываются в восьмеричной системе. В таком 
случае 17.52.86.120 — это не то же самое, что 017.52.86.120. В первом примере ад- 
рес сети равен 17, а во втором - 15. 


Классы адресов 


По традиции все [Р-адреса подразделены на пять классов, показанных на рис. 2.4. 

Адреса класса D используются для группового вещания, а класс Е зарезерви- 
рован для будущих расширений. Остальные классы - А, Ви C ~ предназначены 
для адресации отдельных сетей и хостов. 


01 78 3 
Knacc A D agi ad Идентификатор хоста 

0 2 15 16 31 
Класс В afol Идентификатор сети Идентификатор хоста 
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Идентификатор 
Класс С 008 Идентификатор сети 
0 3 
Knacc D 0058 Для группового вещания 
0 
Класс E add Зарезервировано 


Рис. 2.4. Классы ІР-адресов 


— 


Класс адреса определяется числом начальных единичных битов. У адресов 
класса А вообще нет бита 1 в начале, у адресов класса B — один такой бит, y адре- 
сов класса С — два и тд. Идентификация класса адреса чрезвычайно важна, 
поскольку от этого зависит интерпретация остальных битов адреса. 

Остальные биты любого адреса классов А, В и С разделены на две группы 
Первая часть любого адреса представляет собой идентификатор сети, вторая — 
идентификатор хоста внутри этой сети. 


Примечание Биты идентификации класса также считаются частью иден- 
тификатора сети. Так, 130.50.10.200 — это адрес класса В, в ко- 
тором идентификатор сети равен 0х8232. 


Смысл разбивки адресного пространства на классы в том, чтобы обеспечить 
необходимую гибкость, не теряя адресов Например, класс А позволяет адресовать 
сети с огромным (16777214) количеством хостов. 
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Примечание Существует 2", или 16777216 возможных идентификаторов 
хостов, но адрес 0 и адрес, состоящий из одних единиц, имеют 
специальный смысл. Адрес из одних единиц — это широковеща- 
тельный адрес. [Р-датаграммы, посланные по этому адресу, до- 
ставляются всем хостам в сети. Адрес 0 означает «этот хост» 
и используется хостом как адрес источника, которому в ходе про- 
цедуры начальной загрузки необходимо определить свой истин- 
ный сетевой адрес. Поэтому число хостов в сети всегда равно 
2" — 2, где п — число бит в части адреса, относящейся к хосту. 


Поскольку в адресах класса А под идентификатор сети отводятся 7 бит, то все- 
го существует 128 сетей класса А. 


Примечание Как и в случае идентификаторов хостов, два из этих адресов за- 
резервированы. Адрес 0 означает «эта сеть» и, аналогично хос- 
ту 0, используется для определения адреса сети в ходе начальной 
загрузки. Адрес 127 — это адрес «собственной» сети хоста. Да- 
таграммы, адресованные сети 127, не должны покидать хост- 
отправитель. Часто этот адрес называют «возвратным» (loop- 
back) адресом, поскольку отправленные по нему датаграммы 
«возвращаются» на тот же самый хост. 


На другом полюсе располагаются сети класса С. Их очень много, но в каждой 
может быть не более 254 хостов. Таким образом, адреса класса А предназначены 
для немногих гигантских сетей с миллионами хостов, тогда как адреса класса С — 
для миллионов сетей с небольшим количеством хостов. 

В табл. 2.1 показано, сколько сетей и хостов может существовать в каждом 
классе, а также диапазоны допустимых адресов. Будем считать, что сеть 127 
принадлежит классу А, хотя на самом деле она, конечно, недоступна для адре- 
сации. 


Таблица 2.1. Число сетей, хостов и диапазоны адресов для классов A, Ви C 


Класс Сети Хосты Диапазон адресов 

А 127 16 777 214 0.0.0.1-127.255.255.255 

B 16 384 65 534 128.0.0.0-191.255.255.255 
C 2 097 252 254 192.0.0.0-223.255.255.255 


Первоначально проектировщики набора протоколов TCP/IP полагали, что 
сети будут исчисляться сотнями, а хосты — тысячами. 


Примечание В действительности, как отмечается в работе [Нийета 1995], 
в исходном проекте фигурировали только адреса, которые те- 
перь относятся к классу А. Подразделение на три класса было 
сделано позже, чтобы иметь более 256 сетей. 


з Основы 


Появление дешевых, повсеместно применяемых персональных компьютеров 
привело к значительному росту числа сетей и хостов. Нынешний размер Internet 
намного превосходит ожидания его проектировщиков. 

Такой рост выявил некоторые недостатки классов адресов. Прежде всего, 
число хостов в классах А и В слишком велико. Вспомним, что идентификатор 
сети, как предполагалось, относится к физической сети, например локальной. 
Но никто не станет строить физическую сеть из 65000 хостов, не говоря уже 
о 16000000. Вместо этого большие сети разбиваются на сегменты, взаимосвя- 
занные маршрутизаторами. 

В качестве простого примера рассмотрим два сегмента сети, изображенной 
на рис. 2.5. 


К Internet 


Сегмент 1 


Сегмент 2 


Рис. 2.5. Сеть из двух сегментов 


Если хосту H1 нужно обратиться к хосту H2, то он получает физический ад- 
рес, соответствующий [Р-адресу Н2 (используя для этого метод, свойственный 
данной реализации физической сети), и помещает датаграмму «на провод». 

А если хосту Н1 необходимо обратиться к хосту НЗ? Напрямую послать дата- 
грамму невозможно, даже если известен физический адрес получателя, поскольку H1 
и НЗ находятся в разных сетях. Поэтому Ні должен отправить датаграмму через 
маршрутизатор R1. Если у двух сегментов разные идентификаторы сетей, то H1 
по своей маршрутной таблице определяет, что пакеты, адресованные сегменту 2, 
обрабатываются маршрутизатором R1, и отправляет ему датаграмму в предполо- 
жении, что тот переправит ее хосту НЗ. 

Итак, можно назначить двум сегментам различные идентификаторы сети. Но 
есть и другие решения в рамках системы адресных классов. Во-первых, маршрут- 
ная таблица хоста H1 может содержать по одному элементу для каждого хоста 
в сегменте 2, который определит следующего получателя на пути к этому хосту — 
R1. Такая же таблица должна размещаться на каждом хосте в сегменте 1. Анало- 
гичные таблицы, описывающие достижимость хостов из сегмента 1, следует поме- 
стить на каждом хосте из сегмента 2. Очевидно, такое решение плохо масштаби- 
руется при значительном количестве хостов. Кроме того, маршрутные таблицы 
придется вести вручную, что очень скоро станет непосильной задачей для админи- 
стратора. Поэтому на практике такое решение почти никогда не применяется. 
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Во-вторых, можно реализовать АКР-прокси (ргоху АВР) таким образом, что- 
бы R1 казался для хостов из сегмента 1 одновременно H3, H4 и H5, а для хостов 
из сегмента 2 — H1, Н2 и R2. 


Примечание Агента ARP в англоязычной литературе еще называют promis- 
cuous ARP (пропускающий ARP) unu ARP hack (трюк ARP). 


Это решение годится только B случае, когда B физической сети используется 
протокол ARP (Address Resolution Protocol — протокол разрешения адресов) для 
отображения [Р-адресов на физические адреса. В соответствии с ARP хост, кото- 
рому нужно получить физический адрес, согласующийся с некоторым ІР-адресом, 
должен послать широковещательное сообщение с просьбой хосту, обладающему 
данным [Р-адресом, выслать свой физический адрес. АКР-запрос получают все 
хосты в сети, но отвечает только тот, [Р-адрес которого совпадает с запрошенным. 

Если применяется агент АКР то в случае, когда хосту Н1 необходимо послать 
[Р-датаграмму НЗ, физический адрес которого неизвестен, он посылает АКР- 
запрос физического адреса H3. Но H3 этот запрос не получит, поскольку нахо- 
дится в другой сети. Поэтому на запрос отвечает его агент — R1, сообщая свой 
собственный адрес. Когда R1 получает датаграмму, адресованную H3, он пере- 
правляет ее конечному адресату. Все происходит так, будто НЗ и H1 находятся 
в одной сети. 

Как уже отмечалось, агент АКР может работать только в сетях, которые ис- 
пользуют протокол ARP и к тому же имеют сравнительно простую топологию. 
Подумайте, что случится при наличии нескольких маршрутизаторов, соединяю- 
щих сегменты 1 и 2. 

Извышесказанного следует, что общий способ организовать сети с нескольки- 
ми сегментами — это назначить каждому сегменту свой идентификатор сети. Ho 
у этого решения есть недостатки. Во-первых, при этом возможна потеря многих ад- 
ресов в каждой сети. Так, если у любого сегмента сети имеется свой адрес класса В, 
то большая часть ІР-адресов просто не будет использоваться. 

Во-вторых, маршрутная таблица любого узла, который направляет датаграм- 
мы напрямую в комбинированную сеть, должна содержать по одной записи для 
каждого сегмента. В указанном примере это не так страшно. Но вообразите сеть из 
нескольких сотен сегментов, а таких сетей может быть много. Понятно, что разме- 
ры маршрутных таблиц станут громадными. 


Примечание Эта проблема более серъезна, чем может показаться на первый 
взгляд. Объем памяти маршрутизаторов обычно ограничен, 
и нередко маршрутные таблицы размещаются в памяти специ- 
ального назначения на сетевых картах. Реальные примеры от- 
каза маршрутизаторов из-за роста маршрутных таблиц рас- 
сматриваются в работе [Нийета 1995]. 


Обратите внимание, что эти проблемы не возникают при наличии хотя бы од- 
ного идентификатора сети. [Р-адреса не остаются неиспользованными, поскольку 
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при потребности в новых хостах можно всегда добавить новый сегмент. С другой сто- 
роны, так как имеется лишь один идентификатор сети, в любой маршрутной таблице 
необходима всего одна запись для отправки датаграмм любому хосту в этой сети. 


Подсети 


Мне хотелось найти решение, сочетающее два достоинства: во-первых, неболь- 
шие маршрутные таблицы и эффективное использование адресного пространства, 
обеспечиваемые единым идентификатором сети, во-вторых, простота маршрути- 
зации, характерная для сетей, имеющих сегменты с разными идентификаторами 
сети. Желательно, чтобы внешние хосты «видели» только одну сеть, а внутрен- 
ние — несколько сетей, по одной для каждого сегмента. 

Это достигается с помощью механизма подсетей. Идея очень проста. Посколь- 
ку внешние хосты для принятия решения о выборе маршрута используют только 
идентификатор сети, администратор может распределять идентификаторы хостов 
по своему усмотрению. Таким образом, идентификатор хоста – это закрытая 
структура, не имеющая вне данной сети интерпретации. 

Разделение на подсети осуществляется по следующему принципу. Одна часть 
идентификатора хоста служит для определения сегмента (то есть подсети), в со- 
став которого входит хост, а другая — для идентификации конкретного хоста. Pac- 
смотрим, например, сеть класса В с адресом 190.50.0.0. Можно считать, что третий 
байт адреса — это идентификатор подсети, а четвертый байт — номер хоста в этой 
подсети. На рис. 2.ба приведена сгруктура адреса с точки зрения внешнего компь- 
ютера. Идентификатор хоста — это поле с заранее неизвестной структурой. На 
рис. 2.66 показано, как эта структура выглядит изнутри сети. Вы видите, что она 
состоит из идентификатора подсети и номера хоста. 


0 15 16 31 
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Два взгляда на адрес сети 
ти Tb HoMe 
Идентификатор сети Подсе мер хоста класса В с подсетями 


В приведенном примере взят адрес класса В, и поле номера хоста выделено по 
границе байта. Но это необязательно. На подсети можно разбивать сети классов 
А, Ви C и часто не по границе байта. С каждой подсетью ассоциируется маска nod- 
сети, которой определяется, какая часть адреса отведена под идентификаторы сети 
и подсети, а какая — под номер хоста. Так, маска подсети для примера, показанно- 
го на рис. 2.66, будет Oxffffff00. B основном маска записывается в десятичной но- 
тации (255.255.255.0), но если разбивка проходит не по границе байта, то удобнее 
первая форма. 


Примечание Обратите внимание, что, хотя говорится о маске подсети, фак- 
тически она выделяет части, относящиеся как к сети, так и к под- 
сети, то есть все, кроме номера хоста. 


Подсети іа 


Предположим, что для идентификатора подсети отведено 10 бит, а для номе- 
ра хоста – 6 бит. Тогда маска подсети будет 255.255.255.192 (OxffffffcO). Как следу- 
ет из рис. 2.7, в результате наложения этой маски на адрес 190.50.7.75 получается 
номер сети/подсети, равный 190.70.7.64. 

Для проверки убедитесь, что адрес 190.50.7.75 принадлежит хосту 11 в под- 
сети 29 сети 190.50.0.0. Важно не забывать, что эта интерпретация имеет смысл 
только внутри сети. Для внешнего мира адрес интерпретируется как хост 1867 
в сети 190.50.0.0. 

Теперь следует выяснить, как маршрутизаторы на рис. 2.5 могут воспользо- 
ваться структурой идентификатора хоста для рассылки датаграмм внутри сети. 
Предположим, что есть сеть класса В с адресом 190.5.0.0 и маска подсети равна 
255.255.255.0. Такая структура показана на рис. 2.66. 


190 50 7 75 


IP-anpec | 10111110 00110010 00000111 | 01001011 


Маска подсети 11111111 11111111 11111111 11000000 


Сеть/подсеть | 10111110 | 00110010 | 00000111 | 01000000 


190 50 7 64 


Рис. 2.7. Наложение маски подсети с помощью операции AND 
для выделения сетевой части ІР-адреса 


Нарис. 2.8 первому сегменту назначен идентификатор подссти 1, а второму ~ иден- 
тификатор подсети 2. Рядом с сетевым интерфейсом каждого хоста указан ero [Р-адрес. 
Обратите внимание, что третий байт каждого адреса — это номер подсети, которой при- 
надлежит интерфейс. Однако внешнему компьютеру эта интерпретация неизвестна. 


190.50.0.0 


190.50.2.1 190.50.2,2 190.50.2.3 190.50.2.4 


190.50.2.0 


Рис. 2.8. Сеть с подсетями 


Возвращаясь к вышесказанному, следует выяснить, что происходит, когда хосту 
H1 нужно обратиться к хосту H3. H1 берет адрес H3 (190.50.2.1) и накладывает на 
него маску подсети (255.255.255.0), получая в результате 190.5.2.0. Поскольку H1 на- 
ходится в подсети 190.5.1.0, то НЗ напрямую недоступен, поэтому OH сверяется со сво- 
ей маршрутной таблицей и обнаруживает, что следующий адрес на пути к H3 - это R1. 


2 Основы 


Примечание Во многих реализациях эти два шага объединены за счет поме- 
щения в маршрутную таблицу обеих подсетей. При поиске мар- 
шрута IP выявляет одно из двух: либо целевая сеть доступна 
непосредственно, либо датаграмму надо отослать промежуточ- 
ному маршрутизатору. 


Затем H1 отображает ІР-адрес R1 на его физический адрес (например, с помо- 
щью протокола АВР) и посылает R1 датаграмму. R1 ищет адрес назначения в своей 
маршрутной таблице, пользуясь той же маской подсети, и определяет местонахож- 
дение H3 в подсети, соединенной с его интерфейсом 190.50.2.4. После чего R1 до- 
ставляет датаграмму хосту НЗ, получив предварительно его физический адрес по IP- 
адресу, — для этого достаточно передать датаграмму сетевому интерфейсу 190.50.2.4. 

А теперь предположим, что H1 необходимо отправить датаграмму H2. При 
наложении маски подсети на адрес H2 (190.5.1.2) получается 190.50.1.0, то есть та 
же подсеть, в которой находится сам хост Н1. Поэтому Н1 нужно только получить 
физический адрес H2 и отправить ему датаграмму напрямую. 

Далее разберемся, что происходит, когда хосту Е из внешней сети нужно отпра- 
вить датаграмму H3. Поскольку 190.50.2.1 — адрес класса B, то маршрутизатору на 
границе сети хоста E известно. что НЗ находится в сети 190.50.0.0. Так как шлюзом 
в эту сеть является R2, рано или поздно датаграмма от хоста E дойдет до этого мар- 
шрутизатора. С этого момента все совершается так же, как при отправке датаграм- 
мы хостом H 1: R2 накладывает маску, выделяет адрес подсети 190.50.2.0, определя- 
ет R1 в качестве следующего узла на пути к H3 и посылает R1 датаграмму, которую 
тот переправляет H3. Заметьте, что хосту Е неизвестна внутренняя топология сети 
190.50.0.0. Он просто посылает датаграмму шлюзу R2. Только R2 и другие хосты 
внутри сети определяют существование подсетей и маршруты доступа к ним. 

Важный момент, который нужно помнить, — маска подсети ассоциируется c ce- 
тевым интерфейсом и, следовательно, с записью в маршрутной таблице. Это озна- 
чает, что разные подсети в принципе могут иметь разные маски. 

Предположим, что адрес класса В 190.50.0.0 принадлежит университетской сети, 
а каждому факультету выделена подсеть с маской 255.255.255.0 (на рис. 2.8 показа- 
на только часть всей сети). Администратор факультета информатики, которому на- 
значена подсеть 5, решает выделить один сегмент сети Ethernet компьютерному 
классу, а другой — всем остальным факультетским компьютерам. Он мог бы потре- 
бовать у администрации университета еще один номер подсети, но в компьютер- 
ном классе всего несколько машин, так что нет смысла выделять ему адресное про- 
странство, эквивалентное целой подсети класса С. Вместо этого он предпочел 
разбить свою подсеть на два сегмента, то есть создать подсеть внутри подсети. 

Для этого он увеличивает длину поля подсети до 10 бит и использует маску 
255.255.255.192. В результате структура адреса выглядит, как показано на рис. 2.9. 

Старшие 8 бит идентификатора подсети всегда равны 0000 0101 (5), поскольку 
основная сеть адресует всю подсеть как подсеть 5. Биты Х и У определяют, какой 
Еегпеї-сегмент внутри подсети 190.50.5.0 адресуется. Из рис. 2.10 видно, что если 
ХУ = 10, то адресуется подсеть в компьютерном классе, а если ХУ = 01 — оставшаяся 
часть сети. Частично топология подсети 190.50.5.0 изображена на рис. 2.10. 


Ограниченное вещание 
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Идентификатор сети Идентификато Хост 
ТЕ cem для подсети 190.50.5.0 


В верхнем сегменте (подсеть 190.50.1.0) на рис. 2.10 расположен маршрутиза- 
тор R2, обеспечивающий выход во внешний мир, такой же, как на рис. 2.8. Под- 
сеть 190.50.2.0 здесь не показана. Средний сегмент (подсеть 190.50.5.128) — это локаль- 
ная сеть Ethernet в компьютерном классе. Нижний сегмент (подсеть 190.50.5.64) — это 
сеть Ethernet, объединяющая остальные факультетские компьютеры. Для упрощения 
номер хоста каждой машины один и тот же для всех ее сетевых интерфейсов и совпада- 
ет с числом внутри прямоугольника, представляющего хост или маршрутизатор. 


190.50.0.0 


190.50.5.130 


190.50.5.128 


190.50.5.66 190.50.5.67 


190.50.5.65 


190.50.5.64 


Рис. 2.10. Подсеть внутри подсети 


Маска подсети для интерфейсов, подсоединенных к подсетям 190.50.5.64 
и 190.50.5.128, равна 255.255.255.192, a к подсети 190.50.1.0 — 255.255.255.0. 

Эта ситуация в точности аналогична предыдущей, которая рассматривалась 
для рис. 2.8. Так же, как хостам вне сети 190.50.0.0 неизвестно то, что третий байт 
адреса определяет подсеть, так и хосты в сети 190.50.0.0, но вне подсети 190.50.5.0, 
не могут определить, что первые два бита четвертого байта задают подсеть подсе- 
ти 190.50.5.0. 

Теперь кратко остановимся на широковещательных адресах. При использова- 
нии подсетей существует четыре типа таких адресов для вещания: ограниченный, 
на сеть, на подсеть и на все подсети. 


Ограниченное вещание 


Адрес для ограниченного вещания — 255.255.255.255. Вещание называется огра- 
ниченным, поскольку датаграммы, посланные на этот адрес, не уходят дальше 
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маршрутизатора. Они ограничены локальным кабелем. Такое широковещание при- 
меняется, главным образом, во время начальной загрузки, если хосту неизвестен 
свой [Р-адрес или маска своей подсети. 

Процесс передачи широковещательной датаграммы XOCTOM, имеющим несколь- 
ко сетевых интерфейсов, зависит от реализации. Во многих реализациях датаграм- 
ма отправляется только по одному интерфейсу. Чтобы приложение отправило 
широковещательную датаграмму по нескольким интерфейсам, ему необходимо 
узнать у операционной системы, какие интерфейсы сконфигурированы для под- 
держки широковещания. 


Вещание на сеть 


В адресе для вещания на сеть идентификатор сети определяет адрес этой сети, 
а идентификатор хоста состоит из одних единиц. Например, для вещания на сеть 
190.50.0.0 используется адрес 190.50.255.255. Датаграммы, посылаемые на такой 
адрес, доставляются всем хостам указанной сети. 

Требования к машрутизаторам (RFC 1812) [Baker 1995] предусматривают по 
умолчанию пропуск маршрутизатором сообщений, вещаемых на сеть, но эту воз- 
можность можно отключить. Во избежание атак типа «отказ от обслуживания» 
(denial of service), которые используют возможности, предоставляемые направленным 
широковещанием, во многих маршрутизаторах пропуск таких датаграмм, скорее 
всего, будет заблокирован. 


Вещание на подсеть 


В адресе для вещания на все подсети идентификаторы сети и подсети опреде- 
ляют соответствующие адреса, а идентификатор хоста состоит из одних единиц. 
Не зная маски подсети, невозможно определить, является ли данный адрес адре- 
сом для вещания на подсеть. Например, адрес 190.50.1.255 можно трактовать как 
адрес для вещания на подсеть только при условии, если маршрутизатор имеет ин- 
формацию, что маска подсети равна 255.255.255.0. Если же известно, что маска 
подсети равна 255.255.0.0, то это адрес не считается широковещательным. 

При использовании бесклассовой междоменной маршрутизации (СТОК), ко- 
торая будет рассмотрена ниже, широковещательный адрес этого типа такой же, как 
и адрес вещания на сеть; КЕС 1812 предлагает трактовать их одинаково. 


Вещание на все подсети 


В адресе для вещания на все подсети задан идентификатор сети, а адреса под- 
сети и хоста состоят из одних единиц. Как и при вещании на подсеть, для опозна- 
ния такого адреса необходимо знать маску подсети. 

К сожалению, применение адреса для вещания на все подсети сопряжено с не- 
которыми проблемами, поэтому этот режим не внедрен. При использовании 
СТОК этот вид широковещания не нужен и, по ВЕС 1812, «отправлен на свал- 
ку истории». 


Бесклассовая междоменная маршрутизация MENEMN 


Ни один из описанных широковещательных адресов нельзя использовать 
в качестве адреса источника 1Р-датаграммы. И, наконец, следует отметить, что 
в некоторых ранних реализациях TCP/IP, например в системе 4.2BSD, для выде- 
ления широковещательного адреса в поле идентификатора хоста ставились нееди- 
ницы, а нули. 


Бесклассовая междоменная маршрутизация - CIDR 


Теперь вам известно, как организация подсетей решает одну из проблем, свя- 
занных с классами адресов: переполнение маршрутных таблиц. Хотя и в мень- 
шей степени, подсети все же позволяют справиться и с проблемой истощения 
ІР-адресов за счет лучшего использования пула идентификаторов хостов B Npe- 
делах одной сети. 

Еще одна серьезная проблема — это недостаток сетей класса В. Как показано 
нарис. 2.5, существует менее 17000 таких сетей. Поскольку большинство средних 
и крупных организаций нуждается в количестве 1Р-адресов, превышающем воз- 
можности сети класса С, им выделяется идентификатор сети класса В. 

В условиях дефицита сетей класса В организациям приходилось выделять бло- 
ки адресов сетей класса С, но при этом вновь возникает проблема, которую пыта- 
лись решить с помощью подсетей, — растут маршрутные таблицы. 

Бесклассовая междоменная маршрутизация (CIDR) решает эту проблему, вы- 
вернув принцип организации подсетей «наизнанку». Вместо увеличения CIDR 
уменьшает длину идентификатора сети в ІР-адресе. 

Предположим, некоторой организации нужно 1000 ІР-адресов. Ей выделяют 
четыре соседних идентификатора сетей класса С с общим префиксом от 200.10.4.0 
до 200.10.7.0. Первые 22 бита этих идентификаторов одинаковы и представляют 
номер агрегированной сети, в данном случае 200.10.4.0. Как и для подсетей, для 
идентификации сетевой части [Р-адреса используется маска сети. В приведенном 
здесь примере она равна 255.255.252.0 (Oxfffffc00). 

Ho в отличие от подсетей эта маска сети не расширяет сетевую часть адреса, а уко- 
рачивает ее. Поэтому CIDR называют также суперсетями. Кроме того, маска сети 
в отличие от маски подсети экспортируется во внешний мир. Она становится час- 
тью любой записи маршрутной таблицы, ссылающейся на данную сеть. 

Допустим, внешнему маршрутизатору R надо переправить датаграмму по ад- 
ресу 200.10.5.33, который принадлежит одному из хостов в агрегированной сети. 
Он просматривает записи в своей маршрутной таблице, в каждой из которых хра- 
нится маска сети, и сравнивает замаскированную часть адреса 200.10.5.33 с храня- 
щимся в записи значением. Если в таблице есть запись для сети, то в ней будет 
храниться адрес 200.10.4.0 и маска сети 255.255.252.0. Когда выполняется опера- 
ция побитового AND между адресом 200.10.5.33 и этой маской, получается значе- 
ние 200.10.4.0. Это значение совпадает с хранящимся в записи номером подсети, 
так что маршрутизатору известно, что именно по этому адресу следует перепра- 
вить датаграмму. 

Если возникает неоднозначность, то берется самое длинное соответствие. 
Например, в маршрутной таблице может быть также запись с адресом 200.10.0.0 
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и маской сети 255.255.0.0. Эта запись также соответствует адресу 200.10.5.33, но 
поскольку для нее совпадают только 16 бит, а не 22, как в первом случае, то пред- 
почтение отдается первой записи. 


Примечание Может случиться так, umo Internet сервис-провайдер (ISP) «вла- 
deem» всеми [Р-адресами с префиксом 200.10. В соответствии co 
второй из рассмотренных выше записей маршрутизатор отпра- 
вил бы этому провайдеру все датаграммы, адрес назначения ко- 
торых начинается с 200.10. Тогда провайдер смог бы указать 
более точный маршрут, чтобы избежать лишних звеньев в мар- 
шруте или по какой-то иной причине. 


В действительности механизм CIDR более общий. Он называется «бесклассо- 
вым», так как понятие «класса» в нем полностью отсутствует. Таким образом, каж- 
дая запись в маршрутной таблице содержит маску сети, определяющую сетевую 
часть [Р-адреса. Если принять, что адрес принадлежит некоторому классу, то эта 
маска может укоротить или удлинить сетевую часть адреса. Но поскольку в CIDR 
ПОНЯТИЯ «класса» нет, то можно считать, что сетевая маска выделяет сетевую часть 
адреса без изменения ее длины. 

В действительности, маска - это всего лишь число, называемое префиксом, KO- 
торое определяет число бит в сетевой части адреса. Например, для вышеупомяну- 
той агрегированной сети префикс равен 22, и адрес этой сети следовало бы записать 
как 200.10.4.0/22, где /22 обозначает префикс. С этой точки зрения адресацию на 
основе классов можно считать частным случаем CIDR, когда имеется всего четыре 
(или пять) возможных префиксов, закодированных в старших битах адреса. 

Гибкость, с которой CIDR позволяет задавать размер адреса сети, позволяет 
эффективно распределять [Р-адреса блоками, размер которых оптимально COOT- 
ветствует потребностям сети. Вы уже видели, как можно использовать СТОК для 
агрегирования нескольких сетей класса С в одну большую сеть. А для организа- 
ции маленькой сети из нескольких хостов можно выделить лишь часть адресов 
сети класса С. Например, сервис-провайдер выделяет небольшой компании C един- 
ственной ЛВС адрес сети 200.50.17.128/26. В такой сети может существовать до 
62 хостов (28-2). 

В RFC 1518 [Rekhter и Li 1993] при обсуждении вопроса об агрегировании 
адресов и его влиянии на размер маршрутных таблиц рекомендуется выделять 
префиксы ГР-адресов (то есть сетевые части адреса) иерархически. 


Прамечание Иерархическое агрегирование адресов можно сравнить с иерар- 
хической файловой системой вроде тех, что используются 
в UNIX u Windows. Так же, как каталог верхнего уровня содер- 
жит информацию о своих подкаталогах, но не имеет сведений 
о находящихся в них файлах, доменам маршрутизации верхнего 
уровня известно лишь о промежуточных доменах, а не о конк- 
ретных сетях внутри них. Предположим, что региональный 
провайдер обеспечивает весь трафик для префикса 200/8, 
а к нему подключены три локальных провайдера с префиксами 
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200.1/16, 200.2/16 и 200.3/16. У каждого провайдера есть несколько 
клиентов, которым выделены части располагаемого адресного 
пространства (200.1.5/24 и т.д.). Маршрутизаторы, внешние по 
отношению к региональному провайдеру, должны хранить 
в своих таблицах только одну запись ~ 200/8. Этого достаточ- 
но для достижения любого хоста в данном диапазоне адресов. 
Решения о выборе маршрута можно принимать, даже не зная 
о разбиении адресного пространства 200/8. Маршрутизатор 
регионального провайдера должен хранить в своей таблице 
только три записи: по одной для каждого локального провай- 
дера. На самом нижнем уровне локальный провайдер хранит 
записи для каждого своего клиента. Этот простой пример 
позволяет видеть суть агрегирования. 


Почитать RFC 1518 очень полезно, поскольку в этом документе демонстриру- 
ются преимущества использования СТОК. В ВЕС 1519 [Fuller et al. 1993] описаны 
CIDR иее логическое обоснование, а также приведены подробный анализ затрат, CBS- 
занных с СТОК, и некоторые изменения, которые придется внести в протоколы меж- 
доменной маршрутизации. 


Текущее состояние организации подсетей и CIDR 


Подсети в том виде, в каком они описаны в ВЕС 950 [Mogul and Postel 1985], — 
это часть Стандартного протокола (Std. 5). Это означает, что каждый хост, на KO- 
тором установлен стек TCP/IP, обязан поддерживать подсети. 

CIDR (RFC 1517 [Hinden 1993], ВЕС 1518, ВЕС 1519) - часть предложений 
к стандартному протоколу, и потому не является обязательной. Тем не менее СТОК 
применяется в Internet почти повсеместно, и все новые адреса выделяются этим 
способом. Группа по перспективным разработкам B Internet (TESG — Internet Engi- 
neering Steering Group) выбрала CIDR как промежуточное временное решение 
проблемы роста маршрутных таблиц. 

В перспективе обе проблемы — исчерпания адресов и роста маршрутных таб- 
лиц — предполагается решать с помощью версии 6 протокола IP. IPv6 имеет боль- 
шее адресное пространство (128 бит) и изначально поддерживает иерархию. Та- 
кое адресное пространство (включая 64 бита для идентификатора интерфейса) 
гарантирует, что вскоре ІР-адресов будет достаточно. Иерархия 1Ру6-адресов по- 
зволяет держать размер маршрутных таблиц в разумных пределах. 


Резюме 


В этом разделе рассмотрены подсети и бесклассовая междоменная маршрути- 
зация (СТОК). Вы узнали, как они применяются для решения двух проблем, свой- 
ственных адресации на основе классов. Подсети позволяют предотвратить рост 
маршрутных таблиц, обеспечивая в то же время гибкую адресацию. CIDR служит 
для эффективного выделения 1Р-адресов и способствует их иерархическому на- 
значению. 
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Совет 3. Разберитесь, что такое частные адреса и МАТ 


Раньше, когда доступ в Internet еще не был повсеместно распространен, opra- 
низации выбирали произвольный блок [Р-адресов для своих сетей. Считалось, что 
сеть не подключена и «никогда не будет подключена» к внешним сетям, поэтому 
выбор ІР-адресов не имеет значения. Но жизнь не стоит на месте, и в настоящее 
время очень мало сетей, которые не имеют выхода B Internet. 

Теперь необязательно выбирать для частной сети произвольный блок ІР-адре- 
сов. В RFC 1918 [Ве Мег, Moskowitz et al. 1996] специфицированы три блока ад- 
ресов, которые не будут выделяться: 


о 10.0.0.0-10.255.255.255 (префикс 10/8); 
о 172.16.0.0-172.31.255.255 (префикс 172.16/12); 
о 192.168.0.0—192.168.255.255 (префикс 192.168/16). 


Если использовать для своей сети один из этих блоков, то любой хост сможет 
обратиться к другому хосту в этой же сети, не опасаясь конфликта с глобально 
выделенным ІР-адресом. Разумеется, пока сеть не имеет выхода во внешние сети, 
выбор адресов не имеет значения. Но почему бы сразу не воспользоваться одним 
из блоков частных адресов и не застраховаться тем самым от неприятностей, кото- 
рые могут произойти, когда внешний выход все-таки появится? 

Что случится, когда сеть получит внешний выход? Как хост с частным [Р-ад- 
ресом сможет общаться с другим хостом B Internet или другой внешней сети? Ca- 
мый распространенный ответ – нужно воспользоваться преобразованием сетевых 
адресов (Network Address Translation — МАТ). Есть несколько типов устройств, 
поддерживающих МАТ. Среди них маршрутизаторы, межсетевые экраны (firewalls) 
и автономные устройства с поддержкой МАТ. Принцип работы МАТ заключается 
в преобразовании между частными сетевыми адресами и одним или несколькими 
глобально выделенными ІР-адресами. Большинство устройств с поддержкой NAT 
можно сконфигурировать в трех режимах: 


О статический. Адреса всех или некоторых хостов в частной сети отображают- 
ся на один и тот же фиксированный, глобально выделенный адрес; 

о выбор из пула. Устройство с поддержкой МАТ имеет пул глобально выделен- 
ных [Р-адресов и динамически назначает один из них хосту, которому нуж- 
но связаться с хостом во внешней сети; 

о PAT, или преобразование адресов портов (port address translation). Этот ме- 
тод применяется, когда есть единственный глобально выделенный адрес 
(рис. 2.11). При этом каждый частный адрес отображается на один и тот же 
внешний адрес, но номер порта исходящего пакета заменяется уникальным 
значением, которое в дальнейшем используется для ассоциирования входя- 
щих пакетов с частным сетевым адресом. 


На рис. 2.11 представлена небольшая сеть с тремя хостами, для которой ис- 
пользуется блок адресов 10/8. Имеется также маршрутизатор, помеченный МАТ, 
у которого есть адрес в частной сети и адрес B Internet. 


Частные адреса и МАТ 


B Internet 


205.184.151.171 


Ethernet 


Рис. 2.11 
Частная сеть с маршрутизатором, 
10.0.0.1 10.0.0.2 10.0.0.3 который поддерживает МАТ 


Поскольку показан только один глобальный адрес, ассоциированный с МАТ, 
предположим, что маршрутизатор сконфигурирован с возможностью использо- 
вания метода РАТ. Статический режим и режим выбора из пула аналогичны мето- 
ду РАТ, но проще его, поскольку не нужно преобразовывать еще и номера портов. 

Допустим, что хосту H2 надо отправить SYN-cermenr ТСР поадресу 204.71.200.69 — 
на один из Web-cepBepoB www.yahoo.com, — чтобы открыть соединение. На рис. 2.12а 
видно, что у сегмента, покидающего Н2, адрес получателя равен 204.71.200.69.80, 
а адрес отправителя - 10.0.0.2.9600. 


Примечание Здесь использована стандартная нотация, согласно которой 


адрес, записанный в форме A.B.C.D.P означает ІР-адрес 
A.B.C.D и порт P. 


В этом нет ничего особенного, за исключением того, что адрес отправителя 
принадлежит частной сети. Когда этот сегмент доходит до маршрутизатора, МАТ 
должен заменить адрес отправителя Ha 205.184.151.171, чтобы Web-cepnep на сай- 
Te Yahoo знал, куда посылать сегмент ЗУМ/АСК и последующие. Поскольку во 
всех пакетах, исходящих от других хостов в частной сети, адрес отправителя так- 
же будет заменен на 205.184.151.171, МАТ необходимо изменить еще и номер пор- 
Та на некоторое уникальное значение, чтобы потом определять, какому хосту сле- 
дует переправлять входящие пакеты. Исходящий порт 9600 преобразуется в 5555. 
Таким образом, у сегмента, доставленного на сайт Yahoo, адрес получателя будет 
204.71.200.69.80, а адрес отправителя — 205.184.151.171.5555. 


$ = 10.0.0.2.9600 $ = 205 184.151.171.5555 


О = 204.71.200.69.80 D = 204.71.200.69.80 


$ = 204.71.200.69.80 
О = 10.0.0.2.9600 


$ = 204.71.200.69.80 
О = 205.184.151.171.5555 


"= 


Рис. 2.12. Преобразование адресов портов 
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Из puc. 2.126 видно также, что в дошедшем до маршрутизатора ответе Yahoo 
адрес получателя равен 205.184.151.171.5555. МАТ ищет этот номер порта в сво- 
ей внутренней таблице и обнаруживает, что порт 5555 соответствует адресу 
10.0.0.1.9600, так что после получения от маршрутизатора этого пакета в хосте H2 
появится информация, что адрес отправителя равен 204.71.200.69.80, а адрес по- 
лучателя - 10.0.0.1.9600. 

Описанный здесь метод РАТ выглядит довольно примитивно, но есть много 
усложняющих его деталей. Например, при изменении адреса отправителя или но- 
мера исходящего порта меняются как контрольная сумма заголовка ІР-датаграммы, 
так и контрольная сумма ТСР-сегмента, поэтому их необходимо скорректировать. 

В качестве другого примера возможных осложнений рассмотрим протокол пе- 
редачи файлов FTP (File Transfer Protocol) [Reynolds and Postel 1985]. Когда FTP- 
клиенту нужно отправить файл или принять его от ЕТР-сервера, серверу посылает- 
ся команда РОКТ с указанием адреса и номера порта, по которому будет ожидаться 
соединение (для передачи данных) от сервера. При этом МАТ нужно распознать 
ТСР-сегмент, содержащий команду PORT протокола FTP, и подменить в ней ад- 
рес и порт. В команде PORT адрес и номер порта представлены в виде ASCII- 
строк, поэтому при их подмене может измениться размер сегмента. А это, в свою 
очередь, повлечет изменение порядковых номеров байтов. Так что МАТ должен за 
этим следить, чтобы вовремя скорректировать порядковые номера в сегменте под- 
тверждения АСК, а также в последующих сегментах с того же хоста. 

Несмотря на все эти сложности, МАТ работает неплохо и широко распространен. 
В частности, РАТ - это естественный способ подключения небольших сетей к Internet 
в ситуации, когда имеется только одна точка выхода. 


Резюме 


В этом разделе показано, как схема МАТ позволяет использовать один из бло- 
ков частпых сетевых адресов для внутренних хостов, сохраняя при этом возмож- 
ность выхода B Internet. Метод РАТ, в частности, особенно полезен для небольших 
сетей, у которых есть только один глобально выделенный [Р-адрес. К сожалению, 
поскольку РАТ изменяет номер порта в исходящих пакетах, он может оказаться 
несовмесгимым с нестандартными протоколами, которые передают информацию 
о номерах портов в теле сообщения. 


Совет 4. Разрабатывайте и применяйте 
каркасы приложений 


Большинство приложений TCP/IP попадают в одну из четырех категорий: 


о ТСР-сервер; 
a ТСР-клиент; 
о UDP-cepsep; 
о ОО,Р-клиент. 
В приложениях одной категории обычно встречается почти одинаковый «стар- 


товый» код, который инициализирует все, что связано с сетью. Например, ТСР- 
сервер должен поместить в поля структуры sockaddr, in адрес и порт получателя, 


Каркасы приложений вт 


получить от системы сокет типа SOCK, STREAM, привязать к нему выбранный ад- 
рес и номер порта, установить опцию сокета SO, REUSEADDR (совет 23), вызвать 
listen, а затем быть готовым к приему соединения (или нескольких соединений) 
с помощью системного вызова accept. 

На каждом из этих этапов следует проверять код возврата. А часть програм- 
мы, занимающаяся преобразованием адресов, должна иметь дело как с число- 
выми, так и с символическими адресами и номерами портов. Таким образом, 
в любом ТСР-сервере есть порядка 100 почти одинаковых строк кода для вы- 
полнения всех перечисленных выше задач. Один из способов решения этой про- 
блемы - поместить стартовый код в одну или несколько библиотечных функ- 
ций, которые приложение может вызвать. Эта стратегия использована в книге. 
Но иногда приложению нужна слегка видоизмененная последовательность ини- 
циализации. В таком случае придется либо написать ее с нуля, либо извлечь 
нужный фрагмент кода из библиотеки и подправить его. 

Чтобы справиться и с такими ситуациями, можно построить каркас приложе- 
ния, в котором уже есть весь необходимый код. Затем скопировать этот каркас, 
внести необходимые изменения, после чего заняться логикой самого приложения. 
Не имея каркаса, легко поддаться искушению и срезать некоторые углы, напри- 
мер, жестко «зашить» в приложение адреса (совет 29) или сделать еще что-то со- 
мнительное. Разработав каркас, вы сможете убрать все типичные функции в би- 
блиотеку, а каркас оставить только для необычных задач. 

Чтобы сделать программы переносимыми, следует определить несколько мак- 
pocoB, в которых скрыть различия между API систем UNIX и Windows. Например, 
в UNIX системный вызов для закрытия сокета называется close, а B Windows — 
closesocket. Версии этих макросов для UNIX показаны в листинге 2.1. Версии 
для Windows аналогичны, приведены в приложении 2. Доступ к этим макросам из 
каркасов осуществляется путем включения файла skel . h. 


Листинг 2.1. Заголовочный файл skel.h 


skel.h 
1 $difndef | SKELH . 
2 $define | SKEL Н__ 
3 /* версия для UNIX */ 
4 #define INIT() ( program name = \ 
5 strrchr( argv[ 0], '/' ) ) ? ^ 
6 program name** : \ 
7 ( program name = argv[ 0 ] ) 
8 #define EXIT (5) exit( s ) 
9 d&define CLOSE(s) if ( close( s ) ) error( 1, errno, \ 
10 "ошибка close " ) 
11 £define set, errno(e) errno- (e) 
12 S&define isvalidsock(s) (t (s )>=0) 


13 typedef int SOCKET; 


14 #endif /* | SKEL_H_ */ 
skel.h 
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Начнем с каркаса ТСР-сервера. Затем можно приступить к созданию библио- 
теки, поместив в нее фрагменты кода из каркаса. В листинге 2.2 показана функция 


main. 


Листинг 2.2. функция main из каркаса tcpserver.skel 
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dinclude 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
&include 
finclude 


«stdio.h» 
«stdlib.h» 
«unistd.h» 
«stdarg.h» 
«string.h» 
«errno.h» 
«netdb.h» 
«fcntl.h» 
«sys/time.h» 
«sys/socket.h» 
«netinet/in.h» 
«arpa/inet.h» 
"Skel.h" 


char *program name; 


int main( int argc, 


( 


struct sockaddr in local; 
struct sockaddr in peer; 


char *hname; 

char *sname; 

int peerlen; 
SOCKET s1; 

SOCKET в; 

const int on = 1; 


INIT(); 


if ( arge == 2 ) 


( 


hname 
sname 


} 


else 


( 


NULL; 
argv( 1 ]; 


li 


hname = argv( 1 ]; 
sname = argv[ 2 ]; 


Ў 


set address( hname, 
S = socket( AF INET, SOCK, STREAM, 
lisvalidsock( 
error( 1, errno, "ошибка вызова Socket" 


if ( 


| 


char **argv ) 


sname, 


S ) 


Основы 


tcpserver.skel 
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40 
41 
42 


43 
44 
45 


46 
47 
48 
49 
50 
5I 
52 
53 
54 
55 
56 
57 
58 } 


if ( setsockopt( s, SOL SOCKET, SO REUSEADDR, &on, 
sizeof( on ) ) ) 
error( 1, errno, "ошибка вызова setsockopt" ); 


if ( bind( s, ( struct sockaddr * ) &local, 
sizeof( local ) ) ) 
error( 1, errno, "ошибка вызова bind" ); 


if ( listen( s, NLISTEN ) ) 
error( 1, errno, "ошибка вызова listen" ); 
do 


peerlen - sizeof( peer ); 
s1 = accept( s, ( struct sockaddr * )&peer, &peerlen ); 
if ( l!isvalidsock( s1 ) ) 
error( 1, errno, "ошибка вызова accept" ); 
server( 51, &peer ); 


CLOSE( s1 ); 
) while ( 1 ); 
EXIT( 0 ); 


tcpserver.skel 


Включаемые файлы и глобальные переменные 


1-14 


25 


Включаем заголовочные файлы, содержащие объявления используе- 
мых стандартных функций. 

Макрос ТМТТ выполняет стандартную инициализацию, в частности, 
установку глобальной переменной program name для функции error 
и вызов функции WSAStartup при работе на платформе Windows. 


Функция тат 


26-35 


36 


37-45 


46-47 


48-56 


Предполагается, что при вызове сервера ему будут переданы адрес и но- 
мер порта или только номер порта. Если адрес не указан, то привязыва- 
ем к сокету псевдоадрес INADDR, ANY, разрешающий прием соединений 
по любому сетевому интерфейсу. В настоящем приложении в командной 
строке могут, конечно, быть и другие аргументы, обрабатывать их надо 
именно в этом месте. 

Функция set address записывает в поля переменной local типа 
sockaddr in указанные адрес и номер порта. Функция set, address 
показана в листинге 2.3. 

Получаем сокет, устанавливаем в нем опцию SO. REUSEADDR (совет 23) 
и привязываем к нему хранящиеся в переменной 1ocal адрес и номер 
порта. 

Вызываем listen, чтобы сообщить ядру о готовности принимать CO- 
единения от клиентов. 

Принимаем соединения и для каждого из них вызываем функцию 
server. Она может самостоятельно обслужить соединение или создать 
для этого новый процесс. В любом случае после возврата из функции 


EEM Основы 


server соединение закрывается. Странная, на первый взгляд, KOHCT- 
рукция do-whi 1e позволяет легко изменить код сервера Tak, чтобы OH 
завершался после обслуживания первого соединения. Для этого доста- 
точно вместо 


while ( 1 ); 
написать 
while (0); 


Далее обратимся к функции set. address. Она будет использована во всех 
каркасах. Это естественная кандидатура на помещение в библиотеку стандартных 


функций. 


Листинг 2.3. Функция set address 


( 


1 
2 
3 
4 
5 
6 
7 
8 


tcpserver.skel 


static void set address( char *hname, char *sname, 


struct sockaddr in *sap, char *protocol ) 


struct servent *sp; 
struct hostent *hp; 
char *endptr; 

short port; 


bzero( sap, sizeof( *sap ) ); 
sap-»sin family = AF INET; 
if ( hname !- NULL ) 
( 
if ( !inet aton( hname, &sap-»sin addr ) ) 
( 
hp = gethostbyname( hname ); 
if ( hp == NULD ) 
error( 1, 0, "неизвестный хост: %5\п", hname ); 
Sap-»sin addr = *( struct in, addr * )hp-»h, addr; 
| 
} 


else 
Sap-»sin, addr.s, addr = htonl( INADDR ANY ); 
port = strtol( sname, &endptr, 0 ); 
if ( *endptr == '\0' ) 
sap-»sin port = htons( port ); 
else 


{ 
Sp = getservbyname( sname, protocol ); 
if ( sp -- NULL ) 
error( 1, 0, "неизвестный сервис: %5\п", sname ); 
sap-»-sin port = sp-»s. port; 


tcpserver.skel 


Каркасы приложений 


set address 


8-9 Обнулив структуру sockaddr, in, записываем B поле адресного семей- 
ства AF INET. 

10-19 Если hname не NULL, TO предполагаем, что это числовой адрес B CTaH- 
дартной десятичной нотации. Преобразовываем его с помощью функ- 
ции inet  aton, если inet aton возвращает код ошибки, — пытаемся 
преобразовать hname в адрес с помощью gethostbyname. Если и это 
не получается, то печатаем диагностическое сообщение и завершаем 
программу. 

20-21 Если вызывающая программа не указала ни имени, ни адреса хоста, 
устанавливаем адрес INADDR, ANY. 

22-24 Преобразовываем sname в Целое число. Если это удалось, TO записы- 
ваем номер порта в сетевом порядке (совет 28). 

27-30 В противном случае предполагаем, что это символическое название 
сервиса и вызываем getservbyname для получения соответствующе- 
го номера порта. Если сервис неизвестен, печатаем диагностическое со- 
общение и завершаем программу. Заметьте, что getservbyname уже 
возвращает номер порта в сетевом порядке. 


Поскольку иногда приходится вызывать функцию set address напрямую, 
здесь приводится ее прототип: 


" Pdinclude "etcp.h" | "Ner RA ETE a. 


| void set address( char *host, char *port, | 
struct sockaddr in *sap, char *protocol ); 
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Последняя функция — error — показана B листинге 2.4. Это стандартная диа- 
гностическая процедура. 


ВНЕ PIRE Tuer ЗЕЕ НИЕ E 4 


*include "etcp.h" 


Если status не равно 0, To error завершает программу после печати диагнос- 
тического сообщения; в противном случае она возвращает управление. Если егг 
He равно 0, то считается, что это значение системной переменной errno. При этом 
в конец сообщения дописывается соответствующая этому значению строка и чис- 
ловое значение кода ошибки. 

Далее в примерах постоянно используется функция error, поэтому добавим 
ее в библиотеку. 


Листинг 2.4. Функция етог 


tcpserver.skel 
1 void error( int status, int err, char *fmt, ... ) 

2 { 

3 va, list ap; 


ББ Основы 


4 va start( ap, fmt ); 

5 fprintf( stderr, "$s: ", program name ); 
6 vfprintf( stderr, fmt, ap ); 

7 va end( ap ); 

8 


if ( err ) 
9 fprintf( stderr, ": $s (%а) \п", strerror( err ), err ); 
10 if ( status ) 
11 EXIT( status ); 
12 ) 


tcpserver.skel 
B каркас включена также заглушка для функции server: 


static void server(SOCKET s, struct sockaddr in *peerp } 
( 
) 


Каркас можно превратить B простое приложение, добавив код внутрь этой 3a- 
глушки. Например, если скопировать файл tcpserver.skel в hello.c и заме- 
нить заглушку кодом 


static void server(SOCKET s, struct sockaddr in *peerp ) 
( 

send( s, "hello, worldWn', 13, 0); 
) 


TO получим сетевую версию известной программы Ha языке С. Если откомпилиро- 
вать и запустить эту программу, а затем подсоединиться к ней с помощью програм- 
мы telnet, то получится вполне ожидаемый результат: 


bsd: $ hello 9000 

[1] 1163 

bsd: $ telnet localhost 9000 
Trying 127.0.0.1... 

Connected to localhost 

Escape character '^]'. 

hello, world 

Connection closed by foreign host. 


Поскольку каркас tcpserver.skel описывает типичную для ТСР-сервера си- 
туацию, поместим большую часть кода main в библиотечную функцию tcp. server, 
показанную в листинге 2.5. Ее прототип выглядит следующим образом: 


Kinclude "etcp.h" 


| SOCKET tcp server( char *host, char *port ); 
| Возвращаемое значение; сокет в режиме прослушивания (в случае ошибки 3а-| 
вершает программу). 

Параметр host указывает на строку, которая содержит либо имя, либо ІР-ад- 
рес хоста, а параметр port - на строку с символическим именем сервиса или но- 
мером порта, записанным в виде АЗСП-строки. 
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Далее будем пользоваться функцией ccp, server, если не возникнет необхо- 
димость модифицировать каркас кода. 


Листинг 2.5. Функция tcp server 


tcp server.c 


1 SOCKET tcp server( char *hname, char *sname ) 

2 { 

3 struct sockaddr in local; 

4 SOCKET s; 

5 const int оп = 1; 

6 set address( hname, sname, &local, "tcp" ); 

7 S = socket( AF INET, SOCK, STREAM, 0 ); 

8 if ( !isvalidsock( s ) ) 

9 error( 1, errno, "ошибка вызова Socket" ); 
10 if ( setsockopt( s, SOL SOCKET, SO, REUSEADDR, 
11 ( char * )&on, sizeof( on ) ) ) 

12 error( 1, errno, "ошибка вызова setsockopt" }; 
13 if ( bind( s, ( struct sockaddr * ) &local, 
14 sizeof( local ) ) ) 
15 error( 1, errno, “ошибка вызова bind" ); 
16 if ( listen( s, NLISTEN ) ) 
17 error( 1, errno, "ошибка вызова listen" ); 
18 return 8; 
19 ) 
tcp server.c 
Каркас ТСР-клиента 


Рассмотрим каркас приложения ТСР-клиента (листинг 2.6). Если не считать 
функции main и замены заглушки server заглушкой client, то код такой же, как 
для каркаса ТСР-сервера. 


Листинг 2.6. Функция тат из каркаса tcpclient.skel 


{ 


1 
2 
3 
4 
5 
6 
7 
8 
9 
0 
1 


tcpclient.skel 


int main( int argc, char **argv ) 


struct sockaddr in peer; 
SOCKET 8; 


ІМІТ(); 
set address( argv[ 1 ], argv[ 2 ], &peer, "tcp" ); 


S = socket( AF. INET, SOCK STREAM, 0 ); 


if ( 1isvalidsock( s ) ) 
error( 1, errno, "ошибка вызова Socket" ); 
if ( connect( s, ( struct sockaddr * )&peer, 


sizeof( peer ) ) ) 
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12 error( 1, errno, "ошибка вызова connect" ); 
13 client( s, &peer ); 
14 EXIT( O ); 
15 J 


tcpclient.skel 


tcp client.skel 

6-9 Как и B случае tcpserver.skel, записываем B поля структуры 
Sockaddr. in указанные адрес и номер порта, после чего получаем сокет. 

10-11 Вызываем connect для установления соединения с сервером. 

13 После успешного возврата из connect вызываем заглушку client, пе- 
редавая ей соединенный сокет и структуру с адресом сервера. 


Протестировать клиент можно, скопировав каркас в файл helloc.c и дописав 
в заглушку следующий код: 


static void client( SOCKET s, struct sockaddr in *peerp ) 
( 


int rc; 
char buf[ 120 ]; 


bor з) 
( 
rc = recv( s, buf, sizeof( buf ), 0); 
if ( re <= 0 ) 
break; 
write( 1, buf, re }; 


} 


Этот клиент читает из сокета данные и выводит их на стандартный вывод 
до тех пор, пока сервер не пошлет конец файла (EOF). Подсоединившись 
к серверу hello, получаете: 


bsd: $ hello localhost 9000 
hello, world 
bsd: $ 


Поместим фрагменты кода tcpclient.skel в библиотеку, так же, как посту- 
пили с каркасом tcpclient.skel. Новая функция ~ tcp client, приведенная 
в листинге 2.7, имеет следующий прототип: 


#1пс]аЯе "etcp.h" 
| SOCKET tcp client( char *host, char *port ); 


| Возвращаемое значение: соединенный сокет (в случае ошибки завершает про- 
грамму). 
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Как и в случае tcp. server, параметр host содержит либо имя, либо ІР-адрес 
хоста, а параметр port — символическое имя сервиса или номер порта В виде 
АЅСП-строки. 
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Листинг 2.7. Функция tcp client 


м ——tcp client.c 
SOCKET tcp client( char *hname, char *sname ) 


struct sockaddr in peer; 
SOCKET s; 


5 set address( hname, sname, &peer, "tcp" ); 

6 S = Ssocket( AF INET, SOCK STREAM, 0 ); 

7 if ( !isvalidsock( s ) ) 

8 errorí( 1, errno, "ошибка вызова socket" ); 


9 if ( connect( s, ( struct sockaddr * )&peer, 

10 sizeof( peer ) ) ) 

11 error( 1, errno, "ошибка вызова connect" ); 

12 return 8; 
13 } 
Умер client.c 
Каркас UDP-cepBepa 


Каркас UDP-cepBepa в основном похож на каркас ТСР-сервера. Ero отличи- 
тельная особенность — не нужно устанавливать опцию сокета SO. REUSEADDR 
и обращаться к системным вызовам accept и listen, поскольку UDL ~ это про- 
токол, не требующий логического соединения (совет 1). Функция main из каркаса 
приведена в листинге 2.8. 


Листинг 2.8. Функция тат из каркаса udpserver.skel 


udpserver.skel 


1 int main( int argc, char **argv ) 
2-1 

3 struct ѕоскаааг in local; 

4 char *hname; 

5 char *sname; 

6 SOCKET s; 

7 INIT(); 

8 if ( arge == 2 ) 

9 { 

10 hname = NULL; 
11 sname = argv[ 1 ]; 
12 } 

13 else 
14 { 

15 hname = argv[ 1 ]; 

16 sname - argv[ 2 ]; 

17 ) 

18 set address( hname, sname, &local, "udp" ); 
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19 $ = socket( AF INET, SOCK DGRAM, 0 ); 
20 if ( !isvalidsock( s ) ) 
21 error( 1, errno, "ошибка вызова Socket" ); 
22 if ( bind( s, ( struct sockaddr * ) &local, 
23 sizeof( local ) ) ) 
24 error( 1, errno, "ошибка вызова bind" ); 
25 Server( s, &local ); 
26 EXIT( 0 ); 
27 ) 
udpserver.skel 
udpserver.skel 
18 Вызываем функцию set address для записи B поля переменной 


local типа sockaddr in адреса и номера порта, по которому сервер 
будет принимать датаграммы. Обратите внимание, что вместо "Е ср" 
задается третьим параметром "udp". 

19-24 Получаем сокет типа SOCK, DGRAM и привязываем к нему адрес и номер 
порта, хранящиеся в переменной local. 

25 Вызываем заглушку server, которая будет ожидать входящие датаграммы. 


Чтобы получить ЧОР-версию программы «hello world», следует скопировать 
каркас в файл udphelloc.c и вместо заглушки вставить следующий код: 


static void server( SOCKET s, struct sockaddr. in *localp ) 
( 

struct sockaddr, in peer; 

int peerlen; 

char buf{ 1 ]; 


for Lowe) 
{ 
peerlen = sizeof( peer ); 
if ( recvfrom( s, buf, sizeof( buf ), O0, 
( struct sockaddr * )&peer, &peerlen ) < 0 ) 
error( 1, errno, "ошибка вызова recvfrom" ); 
if ( sendto( s, "hello, worldWn", 13, 0, 
( struct sockaddr * )&peer, peerlen ) < 0 ) 
error( 1, errno, "ошибка вызова sendto" ); 


) 


Прежде чем тестировать этот сервер, нужно разработать каркас ОЮР-клиента 
(листинг 2.10). Но сначала нужно вынести последнюю часть main в библиотеч- 
ную функцию цар_зегуег: 
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*include "etcp.h" 
SOCKET udp.server( char *host, char *port ); 


| Возвращаемое значение: Ч ОР-сокет, привязанный к хосту host и порту port | 
(B случае ошибки завершает программу). 


Е а Е ее DA т толиа e. 


Каркасы приложений 1] I | [ ei 


Как обычно, параметры host и port указывают на строки, содержащие соот- 
ветственно имя или [Р-адрес хоста и имя сервиса либо номер порта в виде ASCII- 
строки. 


Листинг 2.9. Функция udp server 


пар server.c 


1 SOCKET чар server( char *hname, char *sname ) 
2 x 

3 SOCKET в; 

4 struct sockaddr in local; 

5 set address( hname, sname, &local, "udp" ); 

6 $ = socket( AF. INET, SOCK DGRAM, 0 ); 

7 if ( l!isvalidsock( s ) ) 

8 error( 1, errno, "ошибка вызова Socket" ); 
9 if ( bind( s, ( struct sockaddr * ) &local, 
10 sizeof( local ) ) ) 
11 error( 1, errno, "ошибка вызова bind" ); 
12 return s; 

13 } 

udp server.c 

Каркас ИБР-клиента 


Функция main в каркасе ООР-клиента выполняет в основном запись в поля 
переменной peer указанных адреса и номера порта сервера и получает сокет типа 
SOCK, DGRAM. Она показана в листинге 2.10. Весь остальной код каркаса такой же, 
как для udpserver.skel. 


Листинг 2.10. Функция тат из каркаса udpclient.skel 


очами UC NO rn 


udpclient.skel 


int main( int argc, char **argv ) 
( 
struct sockaddr. in peer; 
SOCKET s; 
INIT(); 
set address( argv[ 1 ], argv[i 2 ], &peer, "udp" ); 
5 = Ssocket( AF INET, SOCK DGRAM, 0 ); 
if ( !isvalidsock( s ) ) 


error( 1, errno, "ошибка вызова Socket" ); 


client( s, &peer ); 
exit( 0 ) 


ГА 


udpclient.skel 


Теперь можно протестировать одновременно этот каркас и программу udphello, 
для чего необходимо скопировать udpclient.skel в файл udphelloc.c и вместо 
клиентской заглушки подставить такой код: 
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static void client( SOCKET s, struct sockaddr in *реегр ) 
( 


int rc; 
int peerlen; 
char bu£[ 120 ]; 


peerlen = sizeof( *peerp ); 
if ( sendto( s, "", 1, 0, ( struct sockaddr * )peerp, 
peerlen ) < 0 ) 
error( 1, errno, "ошибка вызова sendto" ); 
rc = recvfrom( s, buf, sizeof( buf ), 0, 
( struct sockaddr * )peerp, &peerlen ); 
if (rc >= 0 ) 
write( 1, buf, rc }; 
else 
error( 1, errno, "ошибка вызова recvfrom" ); 


) 


Функция client посылает серверу нулевой байт, читает возвращенную дата- 
грамму, выводит ее в стандартное устройство вывода и завершает программу. Функ- 
ции recvfrom в коде udphello вполне достаточно одного нулевого байта. После 
его приема она возвращает управление основной программе, которая и посылает 
ответную датаграмму. 

При одновременном запуске обеих программ выводится обычное приветствие: 


bsd: $ udphello 9000 & 

[1] 448 

bsd: $ updhelloc localhost 9000 
hello, world 

bsd: S 


Как всегда, следует вынести стартовый код из main в библиотеку. Обратите BHH- 
мание, что библиотечной функции, которой дано имя udp, client (листинг 2.11), 
передается третий аргумент - адрес структуры sockaddr, in;B нее будет помещен 
адрес и номер порта, переданные в двух первых аргументах. 


fKinclude "etcp.h" 


| SOCKET udp client( char *host, char *port, | 

Struct sockaddr in *sap ); | 
| Возвращаемое значение: UDP-coker и заполненная структура РОКА 
C случае ошибки завершает программу). 


Листинг 2. 11. Функция иар_сйет 


иар client.c 


1 SOCKET udp client( char *hname, char *sname, 
2 struct sockaddr in *sap ) 

3 { 

4 SOCKET s; 
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5 set address( hname, sname, sap, "udp" ); 

6 S = Socket( АЕ INET, SOCK, DGRAM, 0 ); 

7 if ( lisvalidsock( s ) ) 

8 error( 1, errno, “ошибка вызова socket" ); 

9 return s; 

10 ) 

udp client.c 

PesioMe 


Прочитав данный раздел, вы узнали, как просто создать целый арсенал карка- 
сов и библиотечных функций. Все построенные каркасы очень похожи и различа- 
ются только несколькими строками в стартовом коде внутри функции main. Ta- 
ким образом, после написания первого каркаса пришлось лишь скопировать код 
и подправить эти несколько строк. Эта методика очень проста. Поэтому, чтобы со- 
здать несколько элементарных клиентов и серверов, потребовалось только вста- 
вить содержательный код вместо заглушек. 

Использование каркасов и написание библиотечных функций закладывает тот 
фундамент, на котором далее легко строить приложения и небольшие тестовые 
программки для их проверки. 


Совет 5. Предпочитайте интерфейс сокетов 
интерфейсу XTI/TLI 


В мире UNIX в качестве интерфейса к коммуникационным протоколам, в част- 
ности к TCP/IP, в основном используются следующие два API: 


о сокеты Беркли; 
о транспортный интерфейс XTI(X/Open Transport Interface). 


Интерфейс сокетов разработан в Университете г. Беркли штата Калифорния 
и вошел в состав созданной там же версии операционной системы UNIX. Он полу- 
чил широкое распространение вместе с версией 4.2BSD (1983), затем был усовер- 
шенствован в версии 4.3BSD Reno (1990) и теперь включается практически во все 
версии UNIX. API сокетов присутствует и в других операционных системах. Так, 
Winsock API популярной в мире Microsoft Windows основан на сокетах из BSD 
[Winsock Group 1997]. 

АРІ интерфейса XTI — это расширение интерфейса к транспортному уровню 
(Transport Layer Interface — TLI), который впервые появился в системе UNIX System 
V Release 3.0 (SVR3) компании AT&T. ТЫ задумывался как интерфейс, не завися- 
щий от протокола, так как он сравнительно легко поддерживает новые протоколы. 
На его дизайн оказала значительное влияние модель протоколов OSI (совет 14). 
В то время многие полагали, что эти протоколы вскоре придут на смену TCP/IP. 
И поэтому, с точки зрения программиста TCP/IP, дизайн этого интерфейса далек 
отоптимального. Кроме того, хотя имена функций TLI очень похожи на использу- 
емые в АРІ сокетов (только они начинаются C t. ), их семантика в ряде случаев 
кардинально отличается. 
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Tor факт, что интерфейс TLI все еще популярен, возможно, объясняется его 
использованием с протоколами Internetwork Packet Exchange/Sequenced Packet 
Exchange (IPX/SPX) в системах фирмы Novell. Поэтому при переносе программ, 
написанных для IPX/SPX, под TCP/IP проще было воспользоваться тем же ин- 
терфейсом TLI [Kacker 1999]. 

В четвертой части первого тома книги «UNIX Network Programming» [Stevens 
1998] имеется прекрасное введение в программирование XTI и подсистемы 
STREAMS. Представить, насколько отличается семантика XTI и сокетов, можно 
хотя бы по тому, что обсуждению XTI посвящено более 100 страниц. 

Надеясь, что протоколы OSI все-таки заменят TCP/IP, многие производители 
ОМІХ-систем рекомендовали писать новые приложения с использованием TLI 
АРТ. Одна фирма-производитель даже заявила, что интерфейс сокетов не будет 
поддерживаться в следующих версиях. Но такие прогнозы оказались несколько 
преждевременными. 

Протоколы OSI можно считать устаревшими, но TLI и последовавший за ним 
ХТ! все еще поставляются в составе ОМ№ІХ-систем, производных or System V. По- 
этому при программировании для UNIX встает вопрос: что лучше использовать — 
сокеты или ХТ[? 

Здесь необходимо напомнить, почему указанные протоколы называются ин- 
терфейсами. Для программиста TCP/IP это всего лишь разные способы доступа 
к стеку TCP/IP. Поскольку именно этот стек реализует коммуникационные про- 
токолы, не имеет значения, какой АР] использует его клиент. Это означает, что 
приложение, написанное с помощью сокетов, может обмениваться данными с при- 
ложением на базе XTI. В системах типа SVR4 оба интерфейса обычно реализуют- 
ся в виде библиотек, осуществляющих доступ к стеку TCP/IP с помощью подсис- 
темы STREAMS. 

Рассмотрим сначала интерфейс ХЛТ. У него есть своя ниша в сетевом програм- 
мировании. Поскольку он не зависит от протокола, с его помощью можно добавить 
в систему UNIX новый протокол, не имея доступа к коду ядра. Проектировщику про- 
токола необходимо лишь реализовать транспортный провайдер в виде STREAMS- 
мультиплексора, связать его с ядром, а потом обращаться к нему через XTI. 


Примечание О том, как писать модули STREAMS, а также о программиро- 
вании ТЫ и STREAMS вы можете прочесть в книге [Rago 1993]. 


Обратите внимание, насколько специфична ситуация: нужно реализовать от- 
сутствующий в системе протокол, когда нет доступа к исходным текстам ядра. 


Примечание Кроме того, этот протокол нужно разработать для системы 
SVR4 или любой другой, поддерживающей STREAMS и XTI/TLI. 
Начиная с версии Solaris 2.6, фирма Sun предоставляет такую 
же функциональность с помощью API сокетов. 


Иногда утверждают, что проще писать не зависящий от протокола код с по- 
мощью XTI/TLI [Rago 1993]. Конечно, «простота» — понятие субъективное, но 
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в разделе 11.9 книги «UNIX Network Programming» Стивенс с помощью сокетов 
реализовал простой, не зависящий от протокола сервер времени дня, который под- 
держивает IP версии 4, IP версии 6 и сокеты в адресном домене UNIX. 

И, наконец, говорят, что при поддержке обоих интерфейсов сокеты обычно 
реализуются поверх TLI/XTI, так что TLI/XTI более эффективен. Это не так. Как 
отмечалось выше, B системах на базе ЗУ R4 оба интерфейса обычно реализованы 
в виде библиотек, напрямую общающихся с подсистемой STREAMS. Фактически 
с версии Solaris 2.6 (Solaris – это версии SV КА, созданные фирмой Sun) сокеты pe- 
ализованы непосредственно в ядре; обращение к ним происходит через вызовы 
системы. 

Большое преимущество сокетов — переносимость. Поскольку сокеты есть прак- 
тически во всех системах c ХТИТИ, их использование гарантирует максималь- 
ную переносимость. Даже если ваше приложение будет работать только под UNIX, 
так как большинство операционных систем, поддерживающих TCP/IP предостав- 
ляет интерфейс сокетов. И лишь немногие системы, не принадлежащие к UNIX, 
содержат интерфейс XTI/TLI (если вообще такие существуют). Например, созда- 
ние приложения, переносимого между UNIX и Microsoft Windows, — сравнительно 
несложная задача, так как Windows поддерживает спецификацию Winsock, в кото- 
рой реализован АР] сокетов. 

Еще одно преимущество сокетов в том, что этот интерфейс проще использо- 
вать, чем ХТИТЦ. Поскольку ХТИТЫ проектировался в основном как общий 
интерфейс (имеются в виду протоколы OST), программисту приходится при его 
использовании писать больше кода, чем при работе с сокетами. Даже сторонники 
XTI/TLI согласны с тем, что для создания приложений TCP/IP следует предпо- 
честь интерфейс сокетов. 

Руководство «Введение в библиотеку подпрограмм», поставляемое в составе 
Solaris 2.6, дает такой совет по выбору API: «При всех обстоятельствах рекоменду- 
ется использовать АРІ сокетов, а не XTI и TLI. Если требуется переносимость на 
другие системы, удовлетворяющие спецификации XPGVAv2, то следует исполь- 
зовать интерфейсы из библиотеки libxnet. Если же переносимость необязательна, 
то рекомендуется интерфейс сокетов из библиотек libsocket и libnsl, a не из libxnet. 
Если выбирать между ХТ! и TLI, то лучше пользоваться интерфейсом XTI (до- 
ступным через libxnet), a не ТЫ (доступным через libnsl)». 


Резюме 


В обычных ситуациях нет смысла использовать интерфейс ХТИТЫ при про- 
граммировании TCP/IP. Интерфейс сокетов проще и обладает большей переноси- 
мостью, а возможности обоих интерфейсов почти одинаковы. 


Совет 6. Помните, что ТСР - потоковый протокол 


ТСР - потоковый протокол. Это означает, что данные доставляются получа- 
телю в виде потока байтов, в котором нет понятий «сообщения» или «границы 
сообщения». В этом отношении чтение данных по протоколу ТСР похоже на чте- 
ние из последовательного порта — заранее не известно, сколько байтов будет воз- 
вращено после обращения к функции чтения. 
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Представим, например, что имеется ТСР-соединение между приложениями 
на хостах А и В. Приложение на хосте А посылает сообщения хосту В. Допустим, 
что у хоста А есть два сообщения, для отправки которых он дважды вызывает 
send - по разу для каждого сообщения. Естественно, эти сообщения передаются 
от хоста А к хосту В в виде раздельных блоков, каждое в своем пакете, как пока- 
зано на рис. 2.13. 

К сожалению, реальная передача данных вероятнее всего будет происходить 
нетак. Приложение на хосте А вызывает send, и вроде бы данные сразу же переда- 
ются на хост В. На самом деле send обычно просто копирует данные в буфер стека 
TCP/IP на хосте А и тут же возвращает управление. ТСР самостоятельно опреде- 
ляет, сколько данных нужно передать немедленно. В частности, он может вообще 
отложить передачу до более благоприятного момента. Принятие такого решения 
зависит от многих факторов, например: окна передачи (объем данных, которые 
хост В готов принять), окна перегрузки (оценка загруженности сети), максималь- 
ного размера передаваемого блока вдоль пути (максимально допустимый объем 
данных для передачи в одном блоке на пути от А кВ) и количества данных в выход 
ной очереди соединения. Подробнее это рассматривается в совете 15. На рис. 2.14 
показано только четыре возможных способа разбиения двух сообщений по паке- 
там. Здесь М ни М i2 ~ первая и вторая части сообщения М „а M, n M,, - соответ- 
ственно части М,. Как видно из рисунка, ТСР не всегда посылает все сообщения 
в одном пакете. 


a| [Mj [Mj | 
6|  j[Me':Mj | 
s) ә] М M | 
M 
хета ELT МГ] rene r) | Ma Мо Md | 


Рис. 2.14. Четыре возможных 
Рис. 2.13. Неправильная модель способа разбиения 
отправки двух сообщений двух сообщений по пакетам 


А теперь посмотрим на эту ситуацию с точки зрения приложения на хосте. 
В общем случае оно не имеет информации относительно количества возвращае- 
мых ТСР данных при обращении к системному вызову recv. Например, когда при 
ложение на хосте В в первый раз читает данные, возможны следующие варианты 


О данных еще нет, и приложение либо блокируется операционной системой 
либо гесу возвращает индикатор отсутствия данных. Это зависит от того, 
был ли сокет помечен как блокирующий и какую семантику вызова recv 
поддерживает операционная система; 

о приложение получает лишь часть данных из сообщения M, если ТСР no- 
сланы пакеты так, как показано на рис. 2.14г; 

о приложение получает все сообщение М,, если ТСР отправлены пакеты, как 
изображено на рис. 2.14а; 
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о приложение получает все сообщение M, и часть или все сообщение М,, как 
представлено на рис. 2.14в. 


НИ Е ЕЕ ИЕН 

Примечание В действительности таких вариантов больше, так как здесь не 
учитывается возможность ошибки и получения конца файла. 
Кроме того, предполагается, что приложение читает все до- 
ступные данные. 


Значительную роль здесь играет время. Если приложением на хосте В пер- 
вое сообщение прочитано не сразу после его отправки, а спустя некоторое время 
после того, как хост А послал второе, то будут прочитаны оба сообщения. Как 
видите, количество данных, доступных приложению в данный момент, — вели- 
чина неопределенная. 

Еще раз следует подчеркнуть, что ТСР — потоковый протокол и, хотя данные 
передаются B ІР-пакетах, размер пакета напрямую не связан с количеством дан- 
ных, переданных ТСР при вызове send. У принимающего приложения нет надеж- 
ного способа определить, как именно данные распределены по пакетам, поскольку 
между соседними вызовами recv может прийти несколько пакетов. 


Примечание Это может произойти, даже если принимающее приложение ре- 
агирует очень быстро. Например, если один пакет потерян (впол- 
не обычная ситуация в Internet, см. совет 12), а последующие 
пришли нормально, то ТСР «придерживает» поступившие дан- 
ные, пока не будет повторно передан и корректно принят про- 
павший пакет. В этот момент приложение получает данные из 
всех поступивших пакетов. 


ТСР следит за количеством посланных и подтвержденных байтов, но не за их 
распределением по пакетам. В действительности, одни реализации при повторной 
передаче потерянного пакета посылают больше данных, другие – меньше. Все это 
настолько важно, что заслуживает выделения: Для ТСР-приложения нет понятия 
«пакет». Если приложение хоть как-то зависит от того, как ТСР распределяет 
данные по пакетам, то его нужно перепроектировать. 

Так как количество возвращаемых в результате чтения данных непредсказуе- 
мо, вы должны быть готовы к обработке этой ситуации. Часто проблемы вообще 
не возникает. Допустим, вы пользуетесь для чтения данных стандартной библио- 
течной функцией fgets. При этом она сама будет разбивать поток байтов на стро- 
ки (листинг 3.3). Иногда границы сообщений бывают важны, тогда приходится ре- 
ализовывать их сохранение на прикладном уровне. 

Самый простой случай — это сообщения фиксированной длины. Тогда вам нуж- 
но прочесть заранее известное число байтов из потока. В соответствии с вышеска- 
занным, для этого недостаточно выполнить простое однократное чтение: 


recv( s, msg, sizeofí( msg ), 0); 


поскольку при этом можно получить меньше, чем sizeof( msg ) байт (рис. 2.14r). 
Стандартный способ решения этой проблемы показан в листинге 2.12. 
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Листинг 2. 12. Функция readn 


readn.c 

1 int readn( SOCKET fd, char *bp, size t len) 

2 { 

3 int cnt; 

4 int rc; 

5 cnt = len; 

6 while ( cnt > 0 ) 

7 ( 

8 rc - recv( fd, bp, cnt, O0 ); 

9 ıf (.ré& «0 ) /* Ошибка чтения? */ 

10 { 

11 if ( errno == EINTR ) /* Вызов прерван? */ 

12 continue; /* Повторить чтение. */ 

13 return -1; /* Вернуть код ошибки. */ 

14 } 

15 if ( rc == ) /* Конец файла? */ 

16 return len - cnt; /* Вернуть неполный счетчик. */ 
17 bp += rc; 

18 cnt -- rc; 

19 ) 
20 return len; 
21. 3 

readn.c 


Функция readn используется точно так же, как read, только она He возвраща- 
ет управления, пока не будет прочитано len байт или не получен конец файла или 
не возникнет ошибка. Ее прототип выглядит следующим образом: 


e E rm, — = =—— — — HÓ—M—XÀ K—M——M—MÓÓ— аа 


tinclude «etcp.h» 
int readn( SOCKET s, char *buf, size t len ); 


Возвращаемое значение: число прочитанных байтов или —1 B случае ошибки. 


(sud ОАО РЕВ БЕ ОЗНА ВОН ВИ ВЕН URN ЕВ БЕН Е ЕЕ НОЕ ЕНИСЕЯ 

Неудивительно, что readn использует ту же технику для чтения заданного 
числа байтов из последовального порта или иного потокового устройства, когда 
количество данных, доступных в данный момент времени, неизвестно. Обычно 
readn (с заменой типа SOCKET на int и recv Ha read) применяется во всех этих 
ситуациях. 

Оператор if 

if ( errno == EINTR ) 
continue; 


в строках 11 и 12 возобновляет выполнение вызова recv, если он прерван сигна- 
лом. Некоторые системы возобновляют прерванные системные вызовы автомати- 
чески, в таком случае эти две строки не нужны. С другой стороны, они не мешают, 
так что для обеспечения максимальной переносимости лучше их оставить. 
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Если приложение должно работать с сообщениями переменной длины, то 
в вашем распоряжении есть два метода. Во-первых, можно разделять записи спе- 
циальными маркерами. Именно так надо поступить, используя стандартную функ- 
цию fgets для разбиения потока на строки. В этом случае естественным разде- 
лителем служит символ новой строки. Если маркер конца записи встретится в теле 
сообщения, то приложение-отправитель должно предварительно найти в сообще- 
нии все такие маркеры и экранировать их либо закодировать как-то еще, чтобы 
принимающее приложение не приняло их по ошибке за конец записи. Например, 
если в качестве признака конца записи используется символ-разделитель RS, то 
отправитель сначала должен найти все вхождения этого символа в тело сообще- 
ния и экранировать их, например, добавив перед каждым символ \. Это означает, 
что данные необходимо сдвинуть вправо, чтобы освободить место для символа эк- 
ранирования. Его, разумеется, тоже необходимо экранировать. Так, если для экра- 
нирования используется символ \, то любое его вхождение в тело сообщения сле- 
дует заменить на NN. 


Другие данные в заголовке 


Заголовок 


Данные переменной длины 


Рис. 2.15 
Формат записи переменной длины 


Принимающей стороне нужно просмотреть все сообщение, удалить символы 
экранирования и найти разделители записей. Поскольку при использовании мар- 
керов конца записи все сообщение приходится просматривать дважды, этот метод 
лучше применять только при наличии «естественного» разделителя, например 
символа новой строки, разделяющего строки текста. 

Другой метод работы с сообщениями переменной длины предусматривает 
снабжение каждого сообщения заголовком, содержащим (как минимум) длину 
следующего за ним тела. Этот метод показан на рис. 2.15. 

Принимающее приложение читает сообщение в два приема: сначала заголовок 
фиксированной длины, и из него извлекается переменная длина тела сообщения, 
а затем – само тело. В листинге 2.13 приведен пример для простого случая, когда 
В заголовке хранится только длина записи. 


Листинг 2.13. Функция для чтения записи переменной длины 


геааугес. с 


int readvrec( SOCKET fd, char *bp, size t len ) 


1 
2 { 

3 u, int32. t reclen; 
4 int rc; 

5 


/* Прочитать длину записи. */ 


о 


Основы 


sizeof( u int32 t ) ); 


readvrec.c 


6 rc = readní( fd, ( char * )&reclen, 
7 if ( rc != sizeof( u int32 t ) ) 
8 return rc < 0? -1 Dis 
9 reclen - ntohl( reclen ); 
10 if ( reclen » len ) 
11 ( 
12 а 
13 * He хватает места в буфере для размещения данных - 
14 отбросить их и вернуть код ошибки. 
15 * / 
16 while ( reclen > 0 ) 
17 ( 
18 rc - readn( fd, bp, len ); 
19 if ( rc !- len ) 
20 return гс < 0? -1 0; 
21 reclen -= len; 
22 if ( reclen < len ) 
23 len = reclen; 
24 } 
25 set errno( EMSGSIZE ); 
26 return -1; 
27 ) 
28 /* Прочитать саму запись */ 
29 rc = readn( fd, bp, reclen ); 
30 if ( rc !* reclen ) 
31 return гс < 0? -1 0; 
32 return rc; 
33 } 
Чтение длины записи 
6-8 


Длина записи считывается в переменную reclen. Функция readvrec 


возвращает 0 (конец файла), если число байтов, прочитанных readn, 
не точно совпадает с размером целого, или —1 в случае ошибки. 

9 Размер записи преобразуется из сетевого порядка в машинный. Под- 
робнее об этом рассказывается в совете 28. 


Проверка того, поместится ли запись в буфер 

10-27 Проверяется, достаточна ли длина буфера, предоставленного вызываю- 
щей программой, для размещения в нем всей записи. Если места не хва- 
тит, то данные считываются в буфер частями по len байт, то есть, по 
сути, отбрасываются. Изъяв из потока отбрасываемые данные, функция 
присваивает переменной errno значение EMSGSIZE и возвращает -1. 


Считывание записи 


29-32 Наконец считывается сама запись. readvrec возвращает —1, 0 или 
reclen в зависимости от того, вернула ли readn код ошибки, непол- 
ный счетчик или нормальное значение. 
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SERT 


я 


Поскольку readvrec — функция полезная и ей найдется применение, необхо- 
димо записать ее прототип: 
#include "etcp.h" 
int readvrec( SOCKET s, char *buf, size t len ); 


Возвращаемое значение: число прочитанных 6 байтов или -1. 


В листинге 2.14 дан пример простого сервера, который читает из ТСР-соеди- 
нения записи переменной длины с помощью readvrec и записывает их Ha стан- 
дартный вывод. 


Листинг 2. 14. vrs - сервер, демонстрирующие применение функции readvrec 


vrs.c 

1 &include "etcp.h" 

2 int main( int argc, char **argv ) 

3 { 

4 struct sockaddr_in peer; 

5 SOCKET s; 

6 SOCKET $1; 

7 int peerlen = sizeof( peer ); 

8 int n; 

9 char buf[ 10 ]; 

10 INIT(); 

11 if ( argc == 2 ) 

12 s = tcp server( NULL, argv[ 1 ] ); 

13 else 

14 S = tcp server( argv[ 1 ], argv[i 2 ] ); 

15 sl = accept( s, ( struct sockaddr * )&peer, &peerlen ); 
16 if ( lisvalidsock( s1 ) ) 

17 error( 1, errno, "ошибка вызова accept" ); 

18 for (;; ) 

19 ( 
20 n = readvrec( 51, buf, sizeof( buf ) ); 

21 if (п< 0) 

22 error( 0, errno, "readvrec вернула код ошибки" ); 
23 else if ( == ) 
24 error( 1, 0, "клиент отключился\п" ); 

25 е1зе 

26 write( 1, buf, n ); 
27 ) 
28 EXIT( O ); /* Сюда He попадаем. */ 

29 ) 

vrs.c 


10-17 Инициализируем сервер и принимаем только одно соединение. 
20-24 Вызываем readvrec для чтения очередной записи переменной длины. 
Если произошла ошибка, то печатается диагностическое сообщение 
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и читается следующая запись. Если геадугес возвращает EOF, то ne- 
чатается сообщение и работа завершается. 
26 Выводим записи Ha stdout. 


В листинге 2.15 приведен соответствующий клиент, который читает сообще- 
ния из стандартного ввода, добавляет заголовок с длиной сообщения и посылает 
все это серверу. 


Листинг 2. 15. мс - клиент, посылающий записи переменной длины 


vrc.c 
1 #include "etcp.h" 

2 int main( int argc, char **argv ) 

3 { 

4 SOCKET s; 

5 int n; 

6 struct 

7 { 

8 u_int32_t reclen; 

9 char buf[ 128 ]; 

10 ) packet; 

11 INIT(); 
12 S = tcp client( argv[ 1 ], argv[ 2 ] ); 
13 while ( fgets( packet.buf, sizeof( packet.buf ), stdin ) 
14 17 NULL ) 
15 ( 

16 n = strlen( packet.buf ); 

17 packet.reclen - htonl( n ); 

18 if ( send( Ss, ( char * )&packet, 

19 п + sizeof( packet.reclen ), 0) < 0 ) 
20 error( 1, errno, "ошибка вызова send" ); 
21 ) 
22 EXIT( 0 ); 
23 } 

vrc.c 


Определение структуры packet 

6-10 Определяем структуру packet, в которую будем помещать сообщение 
и его длину перед вызовом send. Тип данных u. int32 t ~ это беззна- 
ковое 32-разрядное целое. Поскольку в Windows такого типа нет, в Bep- 
сии заголовочного файла skel .п для Windows приведено соответству- 
ющее определение типа. 


Примечание В этом примере есть одна потенциальная проблема, о которой 
следует знать. Предположим, что компилятор упаковывает 
данные в структуру, не добавляя никаких символов заполнения. 
Поскольку второй элемент — это массив байтов, в большин- 
стве систем это предположение выполняется, но всегда нужно 
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помнить о возможной недостоверности допущений о способе 
упаковки данных в структуру компилятором. Об этом будет 
рассказано в совете 24 при обсуждении способов для отправки 
нескольких элементов информации одновременно. 


Connect, read и send 

6-10 Клиент соединяется с сервером, вызывая функцию tcp, client. 

13-21 Вызывается fgets для чтения строки из стандартного ввода. Эта стро- 
ка помещается в пакет сообщения. С помощью функции strlen опре- 
деляется длина строки. Полученное значение преобразуется в сетевой 
порядок байтов и помещается в поле reclen пакета. В конце вызыва- 
ется send для отправки пакета серверу. 


Другой способ отправки сообщений, состоящих из нескольких частей, рассмат- 
ривается в совете 24. 

Протестируем эти программы, запустив сервер на машине Sparc, а клиент — 
на машине bsd. Поскольку результаты показаны рядом, видно, что поступает на 
вход клиенту и что печатает сервер. Чтобы сообщение строки 4 уместилось на стра- 
нице, оно разбито на две строчки. 


bsd: $ vrc врагс 8050 sparc: $ vrs 8050 


123 123 

123456789 123456789 

1234567890 VrS: readvrec вернула код ошибки: 
Message too long (97) 

12 12 

^C VYS: клиент отключился 


Поскольку длина буфера сервера равна 10 байт, функция readvrec возвраща- 
ет код ошибки, когда отправляется 11 байт 1,..., 0,<Г.Е>. 


Резюме 


Типичная ошибка, допускаемая начинающими сетевыми программистами, — 
в непонимании того, что ТСР доставляет поток байтов, в котором нет понятия 
«границы записей». В ТСР нет видимой пользователю концепции «пакета». Он 
просто передает поток байтов, и нельзя точно предсказать, сколько байтов будет 
возвращено при очередном чтении. В этом разделе рассмотрено несколько спо- 
собов работы в таких условиях. 


Совет 7. Не надо недооценивать 
производительность ТСР 


ТСР - это сложный протокол, обеспечивающий базовую службу доставки ГР- 
датаграмм надежностью и управлением потоком. В то же время UDP добавляет 
лишь контрольную сумму. Поэтому может показаться, что UDP должен быть на 
порядок быстрее ТСР. Исходя из этого предположения, многие программисты по- 
лагают, что с помощью UDP можно достичь максимальной производительности. 
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Да, действительно, есть ситуации, когда UDP существенно быстрее ТСР. Ho ино- 
гда использование ТСР оказывается эффективнее, чем применение ОПР. 

В сетевом программировании производительность любого протокола зависит 
от сети, приложения, нагрузки и других факторов, из которых не последнюю роль 
играет качество реализации. Единственный надежный способ узнать, какой прото- 
кол и алгоритм работают оптимально, — это протестировать их в предполагаемых 
условиях работы приложения. На практике это, конечно, не всегда осуществимо, но 
часто удается получить представление о производительности, воспользовавшись 
каркасами для построения простых программ, моделирующих ожидаемый сетевой 
трафик. 

Перед созданием тестовых примеров необходимо разобраться, когда и почему 
производительность UDP больше, чем ТСР. Прежде всего, поскольку ТСР слож- 
нее, он выполняет больше вычислений, чем UDP, 


Примечание В работе [Stevens, 1996 ] сообщается, что реализация ТСР в cu- 
стеме 4.4 BSD содержит примерно 4500 строк кода на языке С 
в сравнении с 800 строками для UDP. Естественно, обычно вы- 
полняется намного меньше строк, но эти числа отражают срав- 
нительную сложность кода. 


Ho в типичной ситуации большая часть времени процессора в обоих прото- 
колах тратится на копирование данных и вычисление контрольных сумм (совет 26), 
поэтому здесь нет большой разницы. В своей работе [Partridge 1993] Джекоб- 
сон описывает экспериментальную версию ТСР в которой для выполнения всего 
кода обычно требуется всего 30 машинных инструкций RISC (исключая вычисле- 
ние контрольных сумм и копирование данных в буфер пользовательской програм- 
мы, которые производятся одновременно). 

Нужно отметить, что для обеспечения надежности ТСР должен посылать под- 
тверждения (АСК-сегменты) на каждый принятый пакет. Это несколько увеличи- 
вает объем обработки на обоих концах. Во-первых, принимающая сторона может 
включить АСК в состав данных, которые она посылает отправителю. В действи- 
тельности во многих реализациях ТСР отправка АСК задерживается на несколь- 
ко миллисекунд: предполагается, что приложение-получатель вскоре сгенерирует 
ответ на пришедший сегмент. Во-вторых, ТСР не обязан подтверждать каждый 
сегмент. В большинстве реализаций при нормальных условиях АСК посылается 
только на каждый второй сегмент. 


Примечание ВЕС 1122 [Braden 1989] рекомендует откладывать посылку АСК 
до 0,5 с при подтверждении каждого второго сегмента. 


Еще одно принципиальное отличие между ТСР и UDP втом, что ТСР требует 
логического соединения (совет 1) и, значит, необходимо заботиться об его уста- 
новлении и разрыве. Для установления соединения обычно требуется обменяться 
тремя сегментами. Для разрыва соединения нужно четыре сегмента, которые, кро- 
ме последнего, часто можно скомбинировать с сегментами, содержащими данные. 


Производительность ТСР 


BERNER] 


Предположим, что время, необходимое для разрыва соединения B большин- 
стве случаев не расходуется зря, поскольку одновременно передаются данные. 
Следует выяснить, что же происходит во время установления соединения. Как 
показано на рис. 2.16, клиент начинает процедуру установления соединения, по- 
сылая серверу сегмент SYN (синхронизация). В этом сегменте указывается поряд- 
ковый номер, который клиент присвоит первому посланному байту, а также дру- 
гие параметры соединения. В частности, максимальный размер сегмента (MSS), 
который клиент готов принять, и начальный размер окна приема. Сервер в ответ 
посылает свой сегмент ЗУМ, который также содержит подтверждение АСК на сег- 
мент SYN клиента. И, наконец, клиент отсылает АСК на сегмент SYN сервера. На 
этом процедура установления соединения завершается. Теперь клиент может по- 
слать свой первый сегмент данных. 

На рис. 2.16 RTT (round-trip time) — это 
период кругового обращения, TO есть время, Клиент Сервер 
необходимое пакету для прохождения с одно- 
го хоста на другой и обратно. Для установле- 
ния соединения нужно полтора таких периода. 

При длительном соединении между кли- 
ентом и сервером (например, клиент и сервер 
обмениваются большим объемом данных) ука- 
занный период «размазывается» между всеми 
передачами данных, так что существенного 
влияния на производительность это не оказы- 
вает. Однако если речь идет о простой транзак- 
ции, в течение которой клиент посылает за- 
прос, получает ответ и разрывает соединение, Рис. 2.16. Установление 
то время инициализации составляет заметную соединения 
часть от времени всей транзакции. Таким об- 
разом, следует ожидать, что U DP намного превосходит ТСР по производительно- 
сти именно тогда, когда приложение организует короткие сеансы связи. И, наоборот, 
ТСР работает быстрее, когда соединение поддерживается в течении длительного 
времени при передаче больших объемов данных. 

Чтобы протестировать сравнительную производительность ТСР и UDP, а за- 
одно продемонстрировать, как пишутся небольшие тестовые программки, созда- 
дим несколько простых серверов и клиентов. Здесь имеется в виду не полнофунк- 
циональная контрольная задача, а лишь определение производительности двух 
протоколов при передаче большого объема данных. Примером такого рода прило- 
жения служит протокол FTP, 


11/2RTT 


Источник и приемник на базе UDP 


В случае ОБР клиент посылает нефиксированное количество датаграмм, ко- 
торые сервер читает, подсчитывает и отбрасывает. Исходный текст клиента при- 
веден в листинге 2.16. 
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Листинг 2. 16. ООР-клиент, посылающий произвольное число датаграмм 


udpsource.c 
1 #1пс1аае "etcp.h" 

2 int main( int argc, char **argv ) 

3-4 

4 struct sockaddr, in peer; 
5 SOCKET s; 

6 int rc; 

7 int datagrams; 

8 int dgramsz = 1440; 

9 char buf[ 1440 ]; 


10 INIT(); 

11 datagrams = atoi( argv[ 2 ] ); 
12 if ( argc > 3) 

13 dgramsz = atoi( argv[ 3 ] D): 


14 s = udp client( argv[ 1 ], "9000", &peer ); 
15 while ( datagrams-- > 0 ) 


16 { 

17 rc = sendto( s, buf, dgramsz, 0, 

18 ( struct sockaddr * )&peer, sizeof( peer ) ); 
19 if ( rc <= 0) 

20 error( 0, errno, "ошибка вызова Sendto" ); 

21 } 

22 sendto( s, "", 0, 0, 

23 ( struct sockaddr * )&реег, sizeof( peer ) ); 

24 EXIT( O ); 

25 ) 


udpsource.c 


10-14 Читаем из командной строки количество посылаемых датаграмм и их 
размер (второй параметр необязателен). Подготавливаем в переменной 
peer UDP-coker с адресом сервера. Вопреки совету 29 номер порта 
9000 жестко «зашит» в код. 

15-21 Посылаем указанное количество датаграмм серверу. 

22-23 Посылаем серверу последнюю датаграмму, содержащую нулевой байт. 
Для сервера она выполняет роль конца файла. 


Текст сервера в листинге 2.17 еще проще. 


Листинг 2.17. Приемник датаграмм 


udpsink.c 
1 finclude "etcp.h" 
2 int main( int argc, char **argv ) 


3 { 

4 SOCKET s; 

5 int rc; 

6 int datagrams - 0; 

7 int rcvbufsz - 5000 * 1440; 
8 char buf[ 1440 ]; 
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9 INIT(); 
10 s = udp.server( NULL, *9000" ); 
11 setsockopt( s, SOL, SOCKET, SO RCVBUF, 


12 ( char * )&rcvbufsz, sizeof( int ) ); 
13 fort ;; ) 
14 { 
15 rc = recv( s, buf, sizeof( buf ), 0); 
16 if ( re <= 0) 
17 break; 
18 datagrams+t+; 
19 } 
20 error( 0, 0, "получено датаграмм: $d \n", datagrams ); 
21 EXIT( 0 ); 
22 } 
udpsink.c 
10 Подготавливаем сервер к приему датаграмм из порта 9000 c любого ин- 
терфейса. 


11-12 Выделяем память для буфера на 5000 датаграмм длиной до 1440 байт. 


Примечание Здесь устанавливается размер буфера 7200000 байт, но нет га- 
рантии, что операционная система выделит столько памяти. 
Хост, работающий под управлением системы BSD, выделил бу- 
фер размером 41600 байт. Этим объясняется потеря дата- 
грамм, которая будет рассмотрена далее. 


13-19 Читаем и подсчитываем датаграммы, пока не придет пустая датаграм- 
ма или не произойдет ошибка. 
20 Выводим число полученных датаграмм на stdrerr. 


Источник и приемник на базе ТСР 


В совете 32 объясняется, что повысить производительность ТСР можно за 
счет выбора правильного размера буферов передачи и приема. Нужно установить 
размер буфера приема для сокета сервера и размер буфера передачи для сокета 
клиента. 

Поскольку в функциях tcp server и tcp client используются размеры бу- 
феров по умолчанию, следует воспользоваться не библиотекой, а каркасами из сове- 
та 4. Сообщать ТСР размеры буферов нужно во время инициализации соедине- 
ния, TO есть до вызова listen в сервере и до вызова connect в клиенте. Поэтому 
невозможно воспользоваться функциями tcp, server и tcp client, так как 
к моменту возврата из них обращение к listen или connect уже произошло. Нач- 
нем с клиента, его код приведен в листинге 2.18. 


Листинг 2.18. Функция тат ТСР-клиента, играющего роль источника 


tcpsource.c 
1 int main( int argc, char **argv ) 
2 { 
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3 struct sockaddr in peer; 
4 char *buf; 
5 SOCKET s; 
6 int c; 
d int blks = 5000; 
8 int sndbufsz - 32 * 1024; 
9 int sndsz = 1440; /* MSS для Ethernet по умолчанию. */ 
10 INIT(); 
11 opterr = 0; 
12 while ( (с = getopt( argc, argv, "s:b:c:" ) ) != EOF ) 
13 ( 
14 switch (c) 
15 ( 
16 case "g" 
17 sndsz = atoi( optarg ); 
18 break; 
19 case "b" 
20 sndbufsz - atoi( optarg ); 
21 break; 
22 case "c" 
23 blks = atoi( optarg ); 
24 break; 
25 case "?" 
26 error( 1, 0, "некорректный параметр: $cWMn", c ); 
27 } 
28 } 
28 if ( argc <= optind ) 
30 error( 1, 0, "He задано имя хоста\п" ); 
31 if ( ( buf = malloc( sndsz ) ) == NULD ) 
32 error( 1, 0, "ошибка вызова mailocMn" ); 


33 set address( argv[ optind ], "9000", &peer, "tcp" 
34 S = socket( AF INET, SOCK STREAM, 0 ); 

35 if ( f!isvalidsock( s ) ) 

36 error( 1, errno, "ошибка вызова Socket" ); 


37 if ( setsockopt( s, SOL SOCKET, SO SNDBUF, 


38 ( char * )&sndbufsz, sizeof( sndbufsz ) ) ) 

39 error( 1, errno, "ошибка вызова setsockopt c опцией 
SO SNDBUF" ); 

40 if ( connect( s, ( struct sockaddr * )&peer, 

41 sizeof( peer ) ) ) 

42 error( 1, errno, "ошибка вызова connect" ); 

43 while( blks-- > 0 ) 

44 send( s, buf, sndsz, 0 ); 

45 EXIT( 0 ); 

46 } 


tcpsource,.c 
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тат 


12-30 В цикле вызываем getopt для получения и обработки параметров из 


31-42 


командной строки. Поскольку эта программа будет использоваться и да- 
лее, то делаем ее конфигурируемой в большей степени, чем необходимо 
для данной задачи. С помощью параметров в командной строке можно 
задать размер буфера передачи сокета, количество данных, передавае- 
мых при каждой операции записи в сокет, и число операций записи. 
Это стандартный код инициализации ТСР-клиента, только добавлено 
еще обращение к set sockopt для установки размера буфера передачи, 
атакже с помощью функции malloc выделен буфер запрошенного раз- 
мера для размещения данных, посылаемых при каждой операции запи- 
си. Обратите внимание, что инициализировать память, на которую 
указывает buf, не надо, так как в данном случае безразлично, какие дан- 
ные посылать. 


43-44 Вызываем функцию send нужное число раз. 


Функция main сервера, показанная в листинге 2.19, взята из стандартного кар- 
Kaca с добавлением обращения к функции getopt для получения из командной 
строки параметра, задающего размер буфера приема сокета, а также вызов функ- 
ции get sockopt для установки размера буфера. 


Листинг 2. 19. Функция тат ТСР-сервера, играющего роль приемника 
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tcpsink.c 


nt main( int argc, char **argv ) 


struct sockaddr in local; 
struct sockaddr in peer; 
int peerlen; 


SOCKET s1; 
SOCKET s; 
int c; 
int rcvbufsz - 32 * 1024; 
const int on = 1; 
INIT(); 
opterr = 0; 
while ( (с = getopt( argc, argv, "b:" ) ) !- EOF ) 
( 
switch ( c ) 
( 
case "p" 
rcvbufsz - atoi( optarg ); 
break; 
case "?" 


error( 1, 0, "недопустимая опция: %с\п"®, с); 


N: Основы 


24 set address( NULL, "9000", &local, "tcp" ); 
25 s = Socket( AF INET, SOCK STREAM, 0 ); 

26 if ( !isvalidsock( s ) ) 

27 error( 1, errno, "ошибка вызова socket" ); 


28 if ( setsockopt( s, SOL, SOCKET, SO REUSEADDR, 
29 ( char * )&on, sizeof( on ) ) ) 
30 error( 1, errno, "ошибка вызова setsockopt SO REUSEADDR" ); 


31 if ( setsockopt( s, SOL SOCKET, SO RCVBUF, 


32 ( char * )&rcvbufsz, sizeof( rcvbufsz ) ) ) 

33 error( 1, errno, "ошибка вызова setsockopt SO RCVBUF" ); 
34 if ( bind( s, ( struct sockaddr * ) &local, 

35 sizeof( local ) ) ) 

36 error( 1, errno, "ошибка вызова bind" ); 

37 listen( s, 5 ); 

38 do 

39 ( 

40 peerlen = sizeof( peer ); 

41 S1 = accept( S, ( struct sockaddr * )&peer, &peerlen ); 
42 if ( !isvalidsock( s1 ) ) 

43 error( 1, errno, "ошибка вызова accept" ); 

44 server( sl, rcvbufsz ); 

45 CLOSE( s1 ); 


46 ) while ( O ); 
47 EXIT( 0 ); 
48 } 
tcpsink.c 


Функция server читает и подсчитывает поступающие байты, пока не обнару- 
жит конец файла (совет 16) или не возникнет ошибка. Она выделяет память под 
буфер того же размера, что и буфер приема сокета, чтобы прочитать максимальное 
количество данных за одно обращение к recv. Текст функции server приведен 
в листинге 2.20. 


Листинг 2.20. Функция server 


tcpsink.c 
static void server( SOCKET s, int rcvbufsz ) 
( 


1 

2 

3 char *buf; 

4 int. rc; 

5 int bytes = 0; 
6 

7 

8 


if ( ( buf » malloc( rcvbufsz ) ) -- NULL ) 
error( 1, 0, "ошибка вызова та11ос\п" ); 
for ( ;; ) 
9 { 
10 rc = гесу( s, buf, rcvbufsz, 0 ); 
11 if (rc <= 0 ) 


12 break; 
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13 bytes += rc; 
14 } 
15 error( 0, 0, "получено байт: $dWMn", bytes ); 
16 } 
tcpsink.c 


Для измерения сравнительной производительности протоколов ТСР и UDP 
при передаче больших объемов данных запустим клиента на машине bsd, а cep- 
вер — на localhost. Физически хосты bsd 
и localhost - это, конечно, одно и TO же, HO, 
как вы увидите, результаты работы программы 
в значительной степени зависят от того, какое 
из этих имен использовано. Сначала запустим пользователь 
клиента и сервер на одной машине, чтобы оце- ^ ^ — Ядро \ 777” о 
нить производительность ТСР и UDRP, устра- 
нив влияние сети. В обоих случаях сегменты 
ТСР или датаграммы UDP инкапсулируются 
в [Р-датаграммах и посылаются возвратному 
интерфейсу 100, который немедленно переправ- 
ляет их процедуре обработки [Р-входа, как пока- 
зано на рис. 2.17. 

Каждый тест был выполнен 50 раз с зада- 
ным размером датаграмм (в случае UDP) или 
числом передаваемых за один раз байтов (в слу- 
чае ТСР), равным 1440. Эта величина вы- 
брана потому, что она близка к максимальному 
размеру сегмента, который ТСР может передать Puc. 2.17. Возвратный интерфейс 
по локальной сети на базе Ethernet. 


Примечание Это число получается max. В одном фрейме Ethernet может быть 
передано не более 1500 байт. Каждый заголовок [Р и ТСР зани- 
мает 20 байт, так что остается 1460. Еще 20 байт резервиро- 
вано для опций ТСР. В системе BSD ТСР посылает 12 байт 
сопциями, поэтому в этом случае максимальный размер сегмен- 
та составляет 1448 байт. 


В табл. 2.2 приведены результаты, усредненные по 50 прогонам. Для каждого 
протокола указано три времени: по часам — время с момента запуска до завершения 
работы клиента; пользовательское — проведенное программой в режиме пользова- 
теля; системное — проведенное программой в режиме ядра. В колонке «Мб/с» ука- 
зан результат деления общего числа посланных байтов на время по часам. В колонке 
«Потеряно» для UDP приведено среднее число потерянных датаграмм. 

Первое, что бросается в глаза, — ТСР работает намного быстрее, когда в каче- 
стве имени сервера выбрано localhost, a He bsd. Для UDP это не так – заметной 
разницы в производительности нет. Чтобы понять, почему производительность 
ТСР так возрастает, когда клиент отправляет данные хосту localhost, запустим 
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программу netstat (совет 38) с опцией -1. Здесь надо обратить внимание на две 
строки (ненужная информация опущена): 


Name Mtu Network Address 
edo 1500 172.30 bsd 
100 16384 127 localhost 


Таблица 2.2. Сравнение производительности ТСР и ЦОР 
при количестве посылаемых байтов, равном 1440 


ТСР 

Сервер Время по часам Пользовательское Системное 
время время Мб/с 

bsd 2,88 0,0292 1,4198 25 
localhost 0,9558 0,0096 0,6316 7,53 
sparc 7,1882 0,016 16226 1,002 

UDP 
Сервер Время по часам Пользовательское Системное 

время время Мб/с Потеряно 

bsd 1,9618 0,0316 1,1934 3,67 336 
localhost 1,9748 0,031 1,1906 3,646 272 
sparc 5,8284 0,0564 0,844 1,235 440 


Как видите, максимальный размер передаваемого блока (МТО - maximum 
transmission unit) для bsd равен 1500, а для localhost - 16384. 


Примечание Такое поведение свойственно реализациям ТСР в системах, про- 
изводных от BSD. Например, в системе Solaris это уже не max. 
При первом построении маршрута к хосту bsd e коде маршру- 
тизации предполагается, что хост находится в локальной сети, 
поскольку сетевая часть ІР-адреса совпадает с адресом интер- 
фейса Ethernet. И лишь при первом использовании маршрута ТСР 
обнаруживает, что он ведет на тот же хост и переключается 
на возвратный интерфейс. Однако к этому моменту все метри- 
ки маршрута, в том числе и МТО, уже установлены в соответ- 
ствии с интерфейсом к локальной сети. 


Это означает, что при посылке данных на localhost ТСР может отправлять 
сегменты длиной до 16384 байт (или 16384 — 20 — 20 — 12 = 16332 байт). Однако 
при посылке данных на хост bsd число байт в сегменте не превышает 1448 (как 
было сказано выше). Но чем больше размер сегментов, тем меньшее их количество 
приходится посылать, а это значит, что требуется меньший объем обработки, и со- 
ответственно снижаются накладные расходы на добавление к каждому сегменту за- 
головков IP n ТСР А результат налицо — обмен данными с XOCTOM localhost проис- 
ходит в три раза быстрее, чем c хостом bsd. 
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Можно заметить, что на хосте localhost ТСР работает примерно в два раза 
быстрее, чем UDP. Это также связано с тем, что ТСР способен объединять несколь- 
ко блоков по 1440 байт в один сегмент, тогда как UDP посылает отдельно каждую 
датаграмму длиной 1440 байт. 

Следует отметить, что в локальной сети UDP примерно на 20% быстрее ТСР, 
но потеря датаграмм значительнее. Потери имеют место даже тогда, когда и сер- 
вер, и клиент работают на одной машине; связаны они с исчерпанием буферов. 
Хотя передача 5000 датаграмм на максимально возможной скорости — это скорее 
отклонение, чем нормальный режим работы, но все же следует иметь в виду воз- 
можность такого результата. Это означает, что UDP не дает никакой гарантии от- 
носительно доставки данной датаграммы, даже если оба приложения работают на 
одной машине. 

По результатам сравнения сеансов с хостами localhost и bsd можно пред- 
положить, что на производительность влияет также длина посылаемых датаграмм. 
Например, если прогнать те же тесты с блоком длиной 300 байт, то, как следует из 
табл. 2.3, ТСР работает быстрее ОПР и на одной машине, и в локальной сети. 

Из этих примеров следует важный вывод: нельзя строить априорные предпо- 
ложения о сравнительной производительности ТСР и UDP. При изменении усло- 
вий, даже очень незначительном, показатели производительности могут очень 
резко измениться. Для обоснованного выбора протокола лучше сравнить их про- 
изводительность на контрольной задаче (совет 8). Когда это неосуществимо на 
практике, все же можно написать небольшие тестовые программы для получения 
хотя бы приблизительного представления о том, чего можно ожидать. 


Таблица. 2.3. Сравнение производительности ТСР и ЦОР 
при количестве посылаемых байтов, равном 300 


ТСР 

Сервер Время по часам Пользовательское Системное 
время время Мб/с 

bsd 1,059 0,0124 0,445 1,416 
sparc 1,5552 0,0084 1,2442 0,965 

UDP 
Сервер Время по часам Пользовательское Системное 

время время Мб/с Потеряно 

bsd 1,6324 0,0324 0,9998 0,919 212 
sparc 1,9118 0,0278 1,4352 0,785 306 


Если говорить o практической стороне вопроса, TO современные реализации 
ТСР досгаточно эффективны. Реально продемонстрировано, что ТСР может ра- 
ботать со скоростью аппаратуры на стомегабитных сетях FDDI. В недавних экс- 
периментах были достигнуты почти гигабитные скорости при работе на персо- 
нальном компьютере [Gallatin et al. 1999]. 


а Основы 


Примечание 29 июля 1999 года исследователи из Университета Дьюка на ра- 
бочей станции XP1000 производства DEC/Compaq на базе npouec- 
copa Alpha в сети Myrinet получили скорости передачи порядка ги- 
габита в секунду. В экспериментах использовался стандартный 
стек TCP/IP из системы FreeBSD 4.0, модифицированный no 
технологии сокетов без копирования (zero-copy sockets). В том 
же эксперименте была получена скорость более 800 Мбит/с на 
персональном компьютере PII 450 МГц и более ранней версии 
сети Myrinet. Подробности можно прочитать на Web-cmpauuue 


http; /wunxocs.duke.edu/ari/trapeze. 


Резюме 


UDP не всегда быстрее, чем ТСР. На сравнительную производительность обо- 
их протоколов влияют разные факторы, и для каждого конкретного случая жела- 
тельно проверять быстродействие на контрольных задачах. 


Совет 8. Не надо заново изобретать ТСР 


Как сказано в совете 7, UDP может быть намного производительнее ТСР 
в простых приложениях, где есть один запрос и один ответ. Это наводит на мысль 
использовать в транзакционных задачах такого рода именно UDP. Однако прото- 
кол UDP не слишком надежен, поэтому эта обязанность лежит на приложении. 

Как минимум, это означает, что приложение должно позаботиться о тех дата- 
граммах, которые теряются или искажаются при передаче. Многие начинающие се- 
тевые программисты полагают, что при работе в локальной сети такая возможность 
маловероятна, и потому полностью игнорируют ее. Но в совете 7 было показано, как 
легко можно потерять датаграммы даже тогда, когда клиент и север находятся на 
одной машине. Поэтому не следует забывать о защите от потери датаграмм. 

Если же приложение будет работать в глобальной сети, то также возможен 
приход датаграмм не по порядку. Это происходит, когда между отправителем 
и получателем было несколько маршрутов. 

В свете вышесказанного можно утверждать, что любое достаточно устойчивое 
ООР-приложение должно обеспечивать: 


о повторную посылку запроса, если ответ не поступил в течение разумного 
промежутка времени; 
О проверку соответствия между ответами и запросами. 


Первое требование можно удовлетворить, если при посылке каждого запроса 
взводить таймер, называемый таймером ретрансмиссии (retransmission timer), или 
КТО-таймером. Если таймер срабатывает до получения ответа, то запрос посыла- 
ется повторно. В совете 20 будет рассмотрено несколько способов эффективного 
решения этой задачи. Второе требование легко реализуется, если в каждый запрос 
включить его порядковый номер и обеспечить возврат этого номера сервером вме- 
сте с ответом. 
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Если приложение будет работать B Internet, то фиксированное время сраба- 
тывания КТО-таймера не годится, поскольку период кругового обращения (RTT) 
между двумя хостами может существенно меняться даже за короткий промежуток 
времени. Поэтому хотелось бы корректировать значение КТО-таймера в зависи- 
мости от условий в сети. Кроме того, если КТО-таймер срабатывает, следует уве- 
личить его продолжительность перед повторной передачей, поскольку она, скорее 
всего, была слишком мала. Это требует некоторой экспоненциальной корректиров- 
ки (exponential backoff) RTO при повторных передачах. 

Далее, если приложение реализует что-либо большее, чем простой протокол 
запрос-ответ, когда клиент посылает запрос и ждет ответа, не посылая дополни- 
тельных датаграмм, или ответ сервера состоит из нескольких датаграмм, то необ- 
ходим какой-то механизм управления потоком. Например, если сервер - это при- 
ложение, работающее с базой данных о кадрах, а клиент просит послать имена 
и адреса всех сотрудников конструкторского отдела, то ответ будет состоять из He- 
скольких записей, каждая из которых посылается в виде отдельной датаграммы. 
Если управление потоком отсутствует, то при этом может быть исчерпан пул бу- 
феров клиента. Обычный способ решения этой проблемы — скользящее окно типа 
того, что используется в ТСР (только подсчитываются не байты, а датаграммы). 

И, наконец, если приложение передает подряд несколько датаграмм, необхо- 
димо позаботиться об управлении перегрузкой. В противном случае такое прило- 
жение может легко стать причиной деградации пропускной способности, которая 
затронет всех пользователей сети. 

Все перечисленные действия, которые должно предпринять основанное на 
протоколе U DP приложение для обеспечения надежности, - это, по сути, вариант 
ТСР. Иногда на это приходится идти. Ведь существуют транзакционные прило- 
жения, в которых накладные расходы, связанные с установлением и разрывом 
ТСР-соединения, близки или даже превышают затраты на передачу данных. 


Примечание Обычный пример — это система доменных имен (Domain Name 
System — DNS), которая используется для отображения домен- 
ного имени хоста на его ІР-адрес. Когда вводится имя хоста 
www.rfc-editor.org в Web-Ópaysepe, реализованный внутри 
браузера клиент DNS посылает DNS-cepeepy ИОР-датаграмму 
с запросом ІР-адреса, ассоциированного с этим именем. Сервер 
в ответ посылает датаграмму, содержащую ІР-адрес 128.9.160.27. 
Подробнее система DNS обсуждается в совете 29. 


Тем не менее необходимо тщательно изучить природу приложения, чтобы IO- 
нять, стоит ли заново реализовывать ТСР. Если приложению требуется надеж- 
ность ТСР, то, быть может, правильное решение - это использование ТСР. 

Маловероятно, что функциональность ТСР, продублированная на приклад- 
ном уровне, будет реализована столь же эффективно, как в настоящем ТСР. Отча- 
сти это связано с тем, что реализации ТСР - это плод многочисленных экспери- 
ментов и научных исследований. С годами ТСР эволюционировал по мере того, 
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как публиковались наблюдения за его работой в различных условиях и сетях, 
в том числе и Internet. 

Кроме того, TCP почти всегда исполняется в контексте ядра. Чтобы понять, 
почему это может повлиять на производительность, представьте себе, что проис- 
ходит при срабатывании В/ТО-таймера в вашем приложении. Сначала ядру нужно 
«пробудить» приложение, для чего необходимо контекстное переключение из ре- 
жима ядра в режим пользователя. Затем приложение должно послать данные. Для 
этого требуется еще одно контекстное переключение (на этот раз в режим ядра), 
в ходе которого данные из датаграммы копируются в буферы ядра. Ядро выбирает 
маршрут следования датаграммы, передает ее подходящему сетевому интерфей- 
cy и возвращает управление приложению — снова контекстное переключение. 
Приложение должно заново взвести КТО-таймер, для чего приходится вновь Ie- 
реключаться. 

А теперь обсудим, что происходит при срабатывании КТО-таймера внутри 
ТСР. У ядра уже есть сохраненная копия данных, нет необходимости повторно KO- 
пировать их из пространства пользователя. Не нужны и контекстные переключе- 
ния. ТСР заново посылает данные. Основная работа связана с передачей данных 
из буферов ядра сетевому интерфейсу. Повторные вычисления не требуются, так 
как ТСР сохранил всю информацию в кэше. 

Еще одна причина, по которой следует избегать дублирования функциональ- 
ности ТСР на прикладном уровне, – потеря ответа сервера. Поскольку клиент не 
получил ответа, у него срабатывает таймер, и он посылает запрос повторно. При 
этом сервер должен дважды обработать один и тот же запрос, что может быть не- 
желательно. Представьте клиент, который «просит» сервер перевести деньги с одно- 
го банковского счета на другой. При использовании ТСР логика повторных попыток 
реализована вне приложения, так что сервер вообще не определит, повторный ли это 
запрос. 


Примечание Здесь не рассматривается возможность сетевого сбоя или отка- 
за одного из хостов. Подробнее это рассматривается в совете 9. 


Транзакционные приложения и некоторые проблемы, связанные с применени- 
ем в них протоколов ТСР и UDP обсуждаются в ВЕС 955 [Braden 1985]. В этой 
работе автор отстаивает необходимость промежуточного протокола между нена- 
дежным, но не требующим соединений UDP, и надежным, но зависящим OT соеди- 
нений ТСР, Соображения, изложенные в этом КЕС, легли в основу предложенного 
Брейденом протокола ТСР Extensions for Transactions (T/TCP), который рассмот- 
рен ниже. 

Один из способов обеспечить надежность ТСР без установления соединения — 
воспользоваться протоколом Т/ТСР. Это расширение ТСР, позволяющее достичь для 
транзакций производительности, сравнимой с UDP за счет отказа (как правило) OT 
процедуры трехстороннего квитирования в ходе установления обычного ТСР-соеди- 
нения и сокращения фазы TIME-WAIT (совет 22) при разрыве соединения. 

Обоснование необходимости Т/ТСР и идеи, лежащие в основе его реализации, orm 
саны в ВЕС 1379 [Braden 1992а]. ВЕС 1644 [Braden 1994] содержит функциональнук, 
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спецификацию Т/ТСР а также обсуждение некоторых вопросов реализации 
В работе [Stevens 1996] рассматривается протокол Т/ТСР приводятся сравнение 
его производительности с UDP изменения в АР! сокетов, необходимые для под- 
держки нового протокола, и его реализация в системе 4.4В$ О. 

К сожалению, протокол Т/ТСР не так широко распространен, хотя и реализо- 
ван в FreeBSD, и существуют дополнения к ядру Linux 2.0.32 и SunOS 4.1.3. 

Ричард Стивенс ведет страницу, посвященную T/TCP, на которой есть ссыл- 
ки на различные посвященные этому протоколу ресурсы. Адрес \’еБ-страницы — 


http;//www.kohala.com/start/ttcp.html. 
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Здесь рассмотрены шаги, необходимые для построения надежного протокола 
поверх UDP. Хотя и существуют приложения, например, DNS, в которых это сде- 
лано, но для корректного решения такой задачи необходимо практически заново 
реализовать ТСР. Поскольку маловероятно, что реализованный на базе UDP npo- 
токол будет так же эффективен, как ТСР, смысла в этом, как правило, нет. 

В этом разделе также кратко обсуждается протокол T/TCP – модификация 
ТСР для оптимизации транзакционных приложений. Хотя Т/ТСР решает многие 
проблемы, возникающие при использовании ТСР для реализации транзакций, он 
пока не получил широкого распространения. 


Совет 9. При всей надежности у ТСР есть 
и недостатки 


Как уже неоднократно отмечалось, ТСР ~ надежный протокол. Иногда эту 
мысль выражают так: «ТСР гарантирует доставку отправленных данных». Хотя эта 
формулировка часто встречается, ее следует признать исключительно неудачной. 

Предположим, что вы отсоединили хост от сети в середине передачи данных. 
В таком случае ТСР не сможет доставить оставшиеся данные А на практике про- 
исходят сбои в сети, аварии серверов, выключение машины пользователями без 
разрыва ТСР-соединения. Все это мешает ТСР доставить по назначению данные, 
переданные приложением. 

Но еще важнее психологическое воздействие фразы о «гарантируемой ТСР 
доставке» на излишне доверчивых сетевых программистов. Разумеется, никто не 
считает, что ТСР обладает магической способностью доставлять данные получа- 
телю, невзирая на все препятствия. Вера в гарантированную доставку проявляет- 
ся в небрежном программировании и, в частности, в легкомысленном отношении 
к проверке ошибок. 


Что такое надежность 


Прежде чем приступать к рассмотрению ошибок, с которыми можно столк- 
нуться при работе с ТСР, обсудим, что понимается под надежностью ТСР. Если 
ТСР не гарантирует доставку всех данных, то что же он гарантирует? Первый во- 
прос: кому дается гарантия? На рис. 2.18 показан поток данных от приложения А вниз 
к стеку TCP/IP на хосте А, через несколько промежуточных маршрутизаторов, 
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вверх к стеку TCP/IP на хосте В и, наконец, к приложению В. Когда ТСР-сегмент 
покидает уровень TCP на хосте А, он «обертывается» B ІР-датаграмму для переда- 
чи хосту на другой стороне. По пути он может пройти через несколько маршрути- 
заторов, но, как видно из рис. 2.18, маршрутизаторы не имеют уровня TCP, они 


лишь переправляют [Р-датаграммы. 
Пользователь 


ТСР 


Интерфейс 


ТСР 


Интерфейс 


Интерфейс 


Рис. 2.18. Сеть с промежуточными маршрутизаторами 


Примечание Некоторые маршрутизаторы в действительности могут пред- 
ставлять собой компьютеры общего назначения, у которых 
есть полный стек TCP/IP, но и в этом случае при выполнении 
функций маршрутизации не задействуются ни уровень ТСР, ни 
прикладной уровень. 


Поскольку известно, что протокол IP ненадежен, то первое место в тракте про- 
хождения данных, в связи с которым имеет смысл говорить о гарантиях, - это уро- 
вень ТСР хоста В. Когда сегмент оказывается на этом уровне, единственное, что 
можно сказать наверняка, — сегмент действительно прибыл. Он может быть запор- 
чен, оказаться дубликатом, прийти не по порядку или оказаться неприемлемым 
еще по каким-то причинам. Обратите внимание, что отправляющий TCP не может 
дать никаких гарантий по поводу сегментов, доставленных принимающему ТСР. 

Однако принимающий ТСР уже готов кое-что гарантировать отправляющему 
ТСР, а именно — любые данные, которые он подтвердил с помощью сегмента АСК, 
а также все предшествующие данные, корректно дошли до уровня TCP. Поэтому 
отправляющий TCP может отбросить их копии, которые y него хранятся. Это не 
означает, что информация уже доставлена приложению или будет доставлена в бу- 
дущем. Например, принимающий хост может аварийно остановиться сразу после 
посылки АСК, еще до того, как данные прочитаны приложением. Это стоит под- 
черкнуть особо: единственное подтверждение приема данных, которое находится 
в ведении TCP, – это вышеупомянутый сегмент АСК. Отправляющее приложение 
не может, полагаясь только на ТСР, утверждать, что данные были благополучно 
прочитаны получателем. Как будет сказано далее, это одна из возможных ошибок 
при работе с TCP, о которых разработчик должен знать. 
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Второе место, в связи с которым имеет смысл говорить о гарантиях, — это само 
приложение В. Вы поняли, нет гарантий, что все данные, отправленные приложе- 
нием А, дойдут до приложения В. Единственное, что ТСР гарантирует приложе- 
нию B, -доставленные данные пришли в правильном порядке и не испорчены. 


Примечание Неискаженность данных гарантируется лишь тем, что ошиб- 
ку можно обнаружить с помощью контрольной суммы. Посколь- 
ку эта сумма представляет собой 16-разрядное дополнение до 
единицы суммы двойных байтов, то она способна обнаружить 
пакет ошибок в 15 бит или менее [Plummer 1978]. Предполагая 
равномерное распределение данных, вероятность принятия 
ТСР ошибочного сегмента за правильный составляет не более 
1/ (2° – 1). Однако в работе [Stone et al. 1998] показано, что 
в реальных данных, встречающихся в сегментах ТСР, частота 
ошибок, не обнаруживаемых с помощью контрольной суммы, 
при некоторых обстоятельствах может быть намного выше. 


Потенциальные ошибки 


Вы уже видели одну из потенциальных ошибок при работе с ТСР: не исклю- 
чено, что подтвержденные ТСР данные не дошли до приложения-получателя. Как 
и большинство других таких ошибок, это довольно редкая ситуация, и, даже если 
она встречается, последствия могут быть не очень печальными. Важно, чтобы про- 
граммист знал об этой неприятности и предусматривал защиту при возможном 
нежелательном результате. Не думайте, что ТСР обо всем позаботится сам, следу- 
ет подумать об устойчивости приложения. 

Защита от упомянутой ошибки очевидна. Если приложению-отправителю важ- 
но иметь информацию, что сообщение дошло до приложения-получателя, то по- 
лучатель должен сам подтвердить факт приема. Часто такое подтверждение при- 
сутствует неявно. Например, если клиент запрашивает у сервера некоторые данные 
и сервер отвечает, то сам ответ – это подтверждение получения запроса. Один из воз- 
можных способов организации явных подтверждений обсуждается в совете 19. 

Более сложный для клиента вопрос - что делать, если сервер не подтверждает 
приема? Это в основном зависит от конкретного приложения, поэтому готового 
решения не существует. Однако стоит отметить, что повторная посылка запроса 
не всегда годится; как говорилось в совете 8, вряд ли будет правильно дважды пе- 
реводить одну сумму со счета на счет. В системах управления базами данных для 
решения такого рода проблем применяется протокол трехфазной фиксации. По- 
добный подход приемлем и для других приложений, гарантирующих, что опера- 
ция выполняется «не более одного раза». Один из примеров — службы параллель- 
ности, фиксации и восстановления (concurrency, commitment, recovery – ССК) - это 
элемент прикладного сервиса в протоколах OSI. Протокол ССК обсуждается B pa- 
Gore [Jain and Agrawala 1993]. 

ТСР - протокол сквозной передачи (end-to-end protocol), то есть он стремит- 
ся обеспечить надежный транспортный механизм между двумя хостами одного 
ранга. Важно, однако, понимать, что конечные точки — это уровни ТСР на обоих 
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хостах, а не приложения. Программы, которым нужны подтверждения на приклад- 
ном уровне, должны самостоятельно это определить. 

Рассмотрим некоторые типичные ошибки. Пока между двумя хостами суще- 
ствует связь, ТСР гарантирует доставку данных по порядку и без искажений. 
Ошибка может произойти только при разрыве связи. Из-за чего же связь может 
разорваться? Есть три причины: 


О постоянный или временный сбой в сети; 
О отказ принимающего приложения; 
О аварийный сбой самого хоста на принимающем конце. 


Каждое из этих событий по-разному отражается на приложении-отправителе. 


Сбой в сети 


Сбои в сети происходят по разным причинам: от потери связи с маршрутиза- 
тором или отрезком опорной сети до выдергивания из разъема кабеля локальнои 
Ethernet-ceru. Сбои, происходящие вне оконечных точек, обычно временные, по- 
скольку протоколы маршрутизации спроектированы так, чтобы обнаруживать по- 
врежденные участки и обходить их. 


Примечание Под оконечной точкой понимается локальная сеть или хост, на 
котором работает приложение. 


Если же ошибка возникает в оконечной точке, то неисправность будет суще- 
ствовать, пока ее не устранят. 

Если промежуточный маршрутизатор не посылает ІСМР-сообщение о том, что 
хост или сеть назначения недоступны, TO ни само приложение, ни стек TCP/IP на 
том же хосте не смогут немедленно узнать о сбое в сети (совет 10). В этом случае 
у отправителя через некоторое время возникнет тайм-аут, и он повторно отправит 
неподтвержденные сегменты. Это будет продолжаться, пока отправляющий ТСР 
не признает доставку невозможной, после чего он обрывает соединение и сообща- 
eT об ошибке. В системе BSD это произойдет после 12 безуспешных попыток 
(примерно 9 мин). При наличии у ТСР ожидающего запроса на чтение операция 
возвращает ошибку, и переменная errno устанавливается B ETIMEDOUT. Если 
ожидающего запроса на чтение нет, то следующая операция записи завершится 
ошибкой. При этом либо будет послан сигнал SIGPIPE, либо (если этот сигнал 
перехвачен или игнорируется) в переменную еггпо записано значение EPIPE. 

Если промежуточный маршрутизатор не может переправить далее 1Р-датаграмму, 
содержащую некоторый сегмент, TO он посылает хосту-отправителю ІСМР-сообще- 
ние о том, что сеть или хост назначения недоступны. В этом случае некоторые реали- 
зации возвращают в качестве кода ошибки значение ЕМЕТОМВЕАСН или ЕНОЗТОМВЕАСН. 


Отказ приложения 


А теперь разберемся, что происходит, когда аварийно или как-либо иначе за- 
вершается приложение на другом конце соединения. Прежде всего следует пони- 
мать, что с точки зрения вашего приложения аварийное завершение другого конца 
не отличается от ситуации, когда приложение на том конце вызывает функцию 
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close (или closesocket, если речь идет o Windows), а затем exit. В обоих слу- 
чаях ТСР на другом конце посылает вашему ТСР сегмент FIN. FIN выступает в роли 
признака конца файла и означает, что у отправившего его приложения нет больше 
данных для вас. Это не значит, что приложение на другом конце завершилось или 
не хочет принимать данные. Подробнее это рассмотрено в совете 16. Как прило- 
жение уведомляется о приходе ЕТМ (и уведомляется ли вообще), зависит от его 
действий в этот момент. Для проработки возможных ситуаций напишем неболь- 
шую клиентскую программу, которая читает строку из стандартного входа, посы- 
лает ее серверу, читает ответ сервера и записывает его на стандартный выход. Ис- 
ходный текст клиента приведен в листинге 2.21. 


Листинг 2.21. ТСР-клиент, который читает и выводит строки 


Еерги.с 

1 &£include "etcp.n" 

2 int main( int argc, char **argv ) 

3 { 

4 SOCKET s; 

5 int rc; 

6 int len; 

7 char buf[ 120 ]; 

8 INIT(); 

9 S = tcp client( argv[ 1 ], argv[ 2 ] ); 

10 while ( fgets( buf, sizeof( buf ), stdin ) != NULL ) 
11 { 

12 len = strlen( buf ); 

13 rc = send( s, buf, len, 0 ); 

14 if (ус «0) 

15 error( 1, errno, "ошибка вызова send" ); 

16 rc - readline( s, buf, sizeof( buf ) ); 

17 if (rc « 0) 

18 error( 1, errno, "ошибка вызова readline" ); 
19 else if ( rc == ) 
20 error( 1, 0, "сервер завершил работу\п" ); 
21 else 
22 fputs( buf, stdout ); 
23 } 

24 EXIT( 0 ); 

25 } 

teprw.c 


8-9 Инициализируем приложение как ТСР-клиент и соединяемся с ука- 
занными в командной строке сервером и портом. 

10-15 Читаем строки из стандартного входа и посылаем их серверу, пока не 
встретится конец файла. 

16-20 После отправки данных серверу читается строка ответа. Функция 
readline получает строку, считывая данные из сокета до символа новой 
строки. Текст этой функции приведен в листинге 2.32 в совете 11. Если 
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readline обнаруживает ошибку или возвращает признак конца файла 
(совет 16), то печатаем диагностическое сообщение и завершаем работу. 
22 В противном случае выводим строку на stdout. 


Для тестирования клиента напишем сервер, который читает в цикле строки, 


поступающие от клиента, и возвращает сообщения о количестве полученных 
строк. Для имитации задержки между приемом сообщения и отправкой ответа сер- 
вер пять секунд «спит». Код сервера приведен в листинге 2.22. 


Листинг 2.22. Сервер, подсчитывающий сообщения 


count.c 

1 £include "etcp.h" 

2 int main( int argc, char **argv ) 

3 { 

4 SOCKET s; 

5 SOCKET 51; 

6 int rc; 

7 int len; 

8 int counter = 1; 

9 char buf[ 120 ]; 
10 INIT()S 

11 S = tcp server( NULL, argv[ 1 ] ); 
12 31 = accept( s, NULL, NULL ); 

13 if ( lisvalidsock( s1 ) ) 

14 error( 1, errno, "ошибка вызова accept" ); 

15 while ( ( rc = readline( 51, buf, sizeof( buf ) ) ) > 0) 
16 ( 

17 sleep( 5 ); 

18 len = sprintf( buf, "получено сообщение %Я\п", counter*t* ); 
19 rc = send( s1, buf, len, 0 ); 
20 if (rc «0 ) 
21 error( 1, errno, "ошибка вызова send" ); 
22 ) 
23 EXIT( 0 ); 
24 ) 

count.c 


Чтобы увидеть, что происходит при крахе сервера, сначала запустим сервер 


и клиент в различных окнах на машине bsd. 


bsd: $ Есрки localhost 9000 

hello 

получено сообщение 1 Это печатается после пятисекундной задержки. 
Здесь сервер был остановлен. 

hello again 

tcprw: ошибка вызова readline: Connection reset by peer (54) 

bsd: $ 


CepBopy посылается одно сообщение, и через 5 c приходит ожидаемый ответ. 


Останавливаете серверный процесс, моделируя аварийный отказ. На стороне 
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клиента ничего не происходит. Клиент блокирован в вызове fgets, а протокол 
ТСР не может передать клиенту информацию о том, что от другого конца получен 
конец файла (FIN). Если ничего не делать, то клиент так и останется блокирован- 
ным в ожидании ввода и не узнает о завершении сеанса сервера. 

Затем вводите новую строку. Клиент немедленно завершает работу с сообще- 
нием о том, что хост сервера сбросил соединение. Вот что произошло: функция 
fgets вернула управление клиенту, которому все еще неизвестно о приходе при- 
знака конца файла от сервера. Поскольку ничто не мешает приложению посылать 
данные после прихода FIN, ТСР клиента попытался послать серверу вторую стро- 
ку. Когда ТСР сервера получил эту строку, он послал в ответ сегмент В$Т (сброс), 
поскольку соединения уже не существует, — сервер завершил сеанс. Когда клиент 
вызывает readline, ядро возвращает ему код ошибки ECONNRESET, сообщая тем 
самым о получении извещения о сбросе. На рис. 2.19 показана хронологическая 
последовательность этих событий. 


Клиент Сервер 


5-я 
секунда 


"Получено 
е 


общени 
ое Сервер 
остановлен 


"hello again т 


Рис. 2.19 
Хронологическая последовательность 
событий при крахе сервера 


Клиент 
завершает 
сеанс 


А теперь рассмотрим ситуацию, когда сервер «падает», не успев закончить об- 
работку запроса и ответить. Снова запустите сервер и клиент в разных окнах на 
машине bsd. 


bsd: $ tcprw localhost 9000 
hello 
Здесь сервер был остановлен. 
tcprw: сервер завершил работу 
bsd: $ 


Посылаете строку серверу, а затем прерываете его работу до завершения вызова 
sleep. Тем самым имитируется крах сервера до завершения обработки запроса. Ha 
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этот раз клиент немедленно получает сообщение об ошибке, говорящее о завершении 
сервера. В этом примере клиент в момент прихода FIN блокирован в вызове readline 
и ТСР может уведомить readline сразу, как только будет получен конец фай- 
ла. Хронологическая последовательность этих событий изображена на рис. 2.20. 


Клиент Сервер 
"hello" 
CepBep 


остановлен рус, 2.20 
Крах сервера в момент, 


Клиент когда в клиенте происходит 
завершает 


Ошибка также может произойти, если игнорировать извещение о сбросе со- 
единения и продолжать посылать данные. Чтобы промоделировать эту ситуацию, 
следует изменить обращение к функции error после readline — вывести диа- 
гностическое сообщение, но не завершаться. Для этого достаточно вместо строки 
17 в листинге 2.21 написать 


error( 0, errno, "ошибка при вызове readline" ); 
Теперь еще раз надо прогнать тест: 


bsd: $ варки localhost 9000 

hello 

получено сообщение 1 
Здесь сервер был остановлен. 

hello again 

tcprw: ошибка вызова readline: Connection reset by peer (54) 
Клиент игнорирует ошибку, но 
ТСР уже разорвал соединение, 

hello for the last time 

Broken pipe Клиент получает сигнал SIGPIPE 


и заверщает работу. 
bsd: $ 


Когда вводится вторая строка, клиент, как и раньше, немедленно извещает об 
ошибке (соединение сброшено сервером), но не завершает сеанс. Он еще раз об- 
ращается к fgets, чтобы получить очередную строку для отправки серверу. Ho 
стоит внести эту строку, как клиент тут же прекращает работу, и командный HH- 
терпретатор сообщает, что выполнение было прервано сигналом SIGPIPE. В этом 
случае при втором обращении к зепа, как и прежде, ТСР послал В$Т, но вы не 
обратили на него внимания. Однако после получения RST клиентский ТСР pa- 
зорвал соединение, поэтому при попытке отправить третью строку он немедлен- 
но завершает клиента, посылая ему сигнал SIGPIPE. Хронология такая же, как 
на рис. 2.19. Разница лишь в том, что клиент «падает» при попытке записи, а не 
чтения. 
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Правильно спроектированное приложение, конечно, не игнорирует ошибки, 
но Такая ситуация может иметь место и в корректно написанных программах. 
Предположим, что приложение выполняет подряд несколько операций записи без 
промежуточного чтения. Типичный пример — ЕТР. Если приложение на другом 
конце «падает», то ТСР посылает сегмент FIN. Поскольку данная программа толь- 
ко пишет, но не читает, B ней не содержится информация о получении этого FIN. 
При отправке следующего сегмента ТСР на другом конце вернет RST. А в npo- 
грамме опять не будет никаких сведений об этом, так как ожидающей операции 
чтения нет. При второй попытке записи после краха отвечающего конца про- 
грамма получит сигнал SIGPIPE, если этот сигнал перехвачен или игнорирует- 
ся — код ошибки ЕРТРЕ. 

Такое поведение вполне типично для приложений, выполняющих многократ- 
ную запись без чтения, поэтому надо отчетливо представлять себе последствия. 
Приложение уведомляется только после второй операции отправки данных завер- 
шившемуся партнеру. Но, так как предшествующая операция привела к сбросу 
соединения, посланные ей данные были потеряны. 

Поведение зависит от соотношения времен. Например, если снова прогнать 
первый тест, запустив сервер на машине Sparc, а клиента — на машине bsd, то по- 
лучается следующее: 


bsd: $ Есргм localhost 9000 

hello 

получено сообщение 1 Это печатается после пятисекундной 
задержки. 
Здесь сервер был остановлен. 

hello again 

tcprw: сервер завершил работу 

bsd: $ 


На этот раз клиент обнаружил конец файла, посланный в результате останов- 
ки сервера. RST по-прежнему генерируется при отправке второй строки, но из-за 
задержек в сети клиент успевает вызвать readline и обнаружить конец файла 
еще до того, как хост bsd получит RST. Если вставить между строками 14 и 15 
в листинге 2.21 строчку 


Sleep( 1 ); 


C целью имитировать обработку на клиенте или загруженность системы, TO полу- 
чится тот же результат, что и при запуске клиента и сервера на одной машине. 


Крах хоста на другом конце соединения 


И последняя ошибка, которую следует рассмотреть, — это аварийный останов 
хоста на другом конце. Ситуация отличается от краха хоста, поскольку ТСР на 
другом конце не может с помощью сегмента FIN проинформировать программу 
о том, что ее партнер уже не работает. 

Пока хост на другом конце не перезагрузят, ситуация будет выглядеть как 
сбой в сети — ТСР удаленного хоста не отвечает. Как и при сбое в сети, ТСР про- 
должает повторно передавать неподтвержденные сегменты. Но в конце концов, 
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если удаленный хост так и не перезагрузится, то ТСР вернет приложению код 
ошибки ETIMEDOUT. 

А что произойдет, если удаленный хост перезагрузится до того, как ТСР пре- 
кратит попытки и разорвет соединение? Тогда повторно передаваемые вами сег- 
менты дойдут до перезагрузившегося хоста, в котором нет никакой информации 
о старых соединениях. В таком случае спецификация ТСР [Postel 1981Ъ] требует, 
чтобы принимающий хост послал отправителю RST. В результате отправитель 
оборвет соединение, и приложение либо получит код ошибки ЕСОММВЕЗЕТ (если 
есть ожидающее чтение), либо следующая операция записи закончится сигналом 
SIGPIPE или ошибкой ЕРТРЕ. 


Резюме 


В этом разделе дано объяснение понятию «надежность ТСР». Вы узнали, что 
не существует гарантированной доставки, и при работе с ТСР могут встретиться 
разнообразные ошибки. Ни одна из этих ошибок не фатальна, но вы должны быть 
готовы к их обработке. 


Совет 10. Помните, что ТСР 
не выполняет опрос соединения 


Программисты, приступающие к изучению семейства протоколов TCP/IP, но 
имеющие опыт работы с другими сетевыми технологиями, часто удивляются, что 
TCP не посылает приложению немедленного уведомления о потере связи. Поэто- 
му некоторые даже считают, что ТСР не пригоден в качестве универсальной тех- 
нологии обмена данными между приложениями. В этом разделе разъясняются 
причины отсутствия у ТСР средств для уведомления, достоинства и недостатки 
такого подхода и способы обнаружения потери связи прикладным программистом. 

Как вы узнали в совете 9, сетевой сбой или крах системы могут прервать сооб- 
щение между хостами, но приложения на обоих концах соединения «узнают» 
об этом не сразу. Приложение-отправитель остается в неведении до тех пор, пока 
ТСР не исчерпает все попытки. Это продолжается довольно долго, в системах на 
базе BSD - примерно 9 мин. Если приложение не посылает данные, то оно может 
вообще не получить информации о потере связи. Например, приложение-сервер 
ожидает, пока клиент не обратится со следующим запросом. Но, поскольку у кли- 
ента нет связи с сервером, следующий запрос не придет. Даже когда ТСР на сторо- 
не клиента прекратит свои попытки и оборвет соединение, серверу об этом будет 
ничего не известно. 

Другие коммуникационные протоколы, например SNA или X.25, извещают 
приложение о потере связи. Если имеется нечто более сложное, чем простая двух- 
точечная выделенная линия, то необходим протокол опроса, который постоянно 
проверяет наличие абонента на другом конце соединения. Это может быть сообще- 
ние типа «есть что-нибудь для отправки?» или скрыты е фреймы, посылаемые в фо- 
новом режиме для непрерывного наблюдения за состоянием виртуального канала. 
В любом случае, за эту возможность приходится расплачиваться пропускной спо- 
собностью сети. Каждое такое опрашивающее сообщение потребляет сетевые ресур- 
сы, которые могли бы использоваться для увеличения полезной нагрузки. 
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Очевидно, одна из причин, по которым ТСР не уведомляет о потере связи не- 
медленно, — это нежелание жертвовать полосой пропускания. Большинству прило- 
жений немедленное уведомление и не нужно. Приложение, которому действитель- 
но необходимо срочно узнавать о недоступности другого конца, может реализовать 
для этой цели собственный механизм. Далее будет показано, как это сделать. 

Есть и философское возражение против встраивания B TCP/IP механизма не- 
медленного уведомления. Один из фундаментальных принципов, заложенных при 
проектировании TCP/IP, - это принцип «оконечного разума» [Saltzer et al. 1984]. 
В применении к сетям упрощенно подразумевается следующее. «Интеллекту» 
нужно находиться как можно ближе к оконечным точкам соединения, а сама сеть 
должна быть относительно «неинтеллектуальной». Именно поэтому ТСР обраба- 
тывает ошибки самостоятельно, не полагаясь на сеть. Как сказано в совете 1, про- 
токол [Р (значит, и построенный на его основе ТСР) делает очень мало предполо- 
жений о свойствах физической сети. Относительно мониторинга наличия связи 
между приложениями этот принцип означает, что такой механизм должен реали- 
зовываться теми приложениями, которым это необходимо, а не предоставляться 
всем приложениям без разбора. В работе [Huitema 1995] принцип «оконечного 
разума» интересно обсуждается в применении к Internet. 

Однако веская причина отсутствия у ТСР средств для немедленного уведом- 
ления о потере соединения связана с одной из главных целей его проектирования: 
способностью поддерживать связь при наличии сбоев в сети. Протокол ТСР - это 
результат исследований, проведенных при финансовой поддержке Министерства 
обороны США, с целью создания надежной технологии связи между компьютера- 
ми. Такая технология могла бы функционировать даже в условиях обрывов сетей 
из-за военных действий или природных катастроф. Часто сетевые сбои быстро 
устраняются или маршрутизаторы находят другой маршрут для соединения. До- 
пуская временную потерю связи, ТСР часто может справиться со сбоями, не ставя 
06 этом в известность приложения. 

Недостаток такого подхода в том, что код, отслеживающий наличие связи, не- 
обходимо встраивать в каждое приложение (которому это нужно), а непродуман- 
ная реализация может привести к ненужному расходу ресурсов или как-то иначе 
повредить пользователям. Но и в этом случае при встраивании мониторинга в при- 
ложение можно осуществить тонкую настройку алгоритма, чтобы он удовлетво- 
рял нуждам приложения и по возможности естественно интегрировался с при- 
кладным протоколом. 


Механизм контролеров 


В действительности протокол ТСР обладает механизмом обнаружения мерт- 
вых соединений — так называемыми контролерами (keep-alive). Но, как вы вскоре 
увидите, для приложений подобный механизм часто бесполезен. Если приложе- 
ние его активирует, то ТСР посылает на другой конец специальный сегмент, ког- 
да по соединению в течение некоторого времени не передавались данные. Если 
хост на другом конце доступен и приложение там все еще работает, то ТСР отвеча- 
ет сегментом АСК. В этом случае ТСР, пославший контролера, сбрасывает время 
простоя в нуль; приложение не получает извещения о том, что имел место обмен 
информацией. 
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Если хост на другом конце работает, a приложение - ger, то ТСР посылает 
в ответ сегмент RST. А ТСР отправивший контролер, разрывает соединение и воз- 
вращает приложению код ЕСОММВЕЗЕТ. Обычно так бывает после перезагрузки 
удаленного хоста, поскольку, как говорилось в совете 9, если бы завершилось всего 
лишь приложение на другом конце, то ТСР послал сегмент FIN. 

Если удаленный хост не посылает в ответ ни АСК, ни RST, то ТСР продолжает 
посылать контролеров, пока не получит сведений, что хост недоступен. В этот мо- 
мент он разрывает соединение и возвращает приложению код ETIMEDOUT либо, если 
маршрутизатор прислал ІСМР-сообщение о недоступности хоста или сети, соответ- 
ственно код EHOSTUNREACH или ENETUNREACH. 

Первая проблема, с которой сталкиваются приложения, нуждающиеся в не- 
медленном уведомлении, при попытке воспользоваться механизмом контроле- 
ров, — это длительность временных интервалов. В соответствии с КЕС 1122 
[Braden 1989], если ТСР реализует механизм контролеров, то по умолчанию Bpe- 
мя простоя должно быть не менее двух часов. И только после этого можно посылать 
контролеров. Затем, поскольку АСК, посланный удаленным хостом, доставляется 
ненадежно, процесс отправки контролеров необходимо несколько раз повторить; 
и лишь тогда можно разрывать соединение. В системе 4.4BSD отправляется девять 
контролеров с интервалом 75 с. 


Примечание Точные величины — деталь реализации. В RFC 1122 не говорится 
о том, сколько и с каким интервалом нужно посылать контро- 
леры, прежде чем разорвать соединение. Утверждается лишь, 
что реализация не должна интерпретировать отсутствие от- 
вета на посылку одного контролера как индикатор прекращения 
соединения. 


Таким образом, в реализациях на основе BSD для обнаружения потери связи 
потребуется 2 ч 11 мин 15 с. Этот срок приобретает смысл, если вы понимаете, что 
назначение контролеров — освободить ресурсы, занятые уже несуществующими со- 
единениями. Такое возможно, например, если клиент соединяется с сервером, а за- 
тем хост клиента неожиданно отключается. Без механизма дежурных серверу при- 
шлось бы ждать следующего запроса от клиента вечно, поскольку он не получит FIN. 


Примечание Эта ситуация очень распространена из-за ошибок пользователей 
персональных компьютеров, которые просто выключают компью- 
тер или модем, не завершив корректно работающие приложения. 


В некоторых реализациях разрешено изменять один или оба временных ин- 
тервала, но это всегда распространяется на систему в целом. Иными словами, из- 
менение затрагивает все ТСР-соединения, установленные данной системой. Это 
и есть основная причина, по которой механизм контролеров почти бесполезен 
в качестве средства мониторинга связи. Период, выбранный по умолчанию, слиш- 
ком велик, а если его сократить, то контролеры перестанут выполнять свою ис- 
ходную задачу — обнаруживать давно «зависшие» соединения. 
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В последней версии стандарта POSIX появилась новейшая опция сокета 
TCP, KEEPALIVE, которая позволяет устанавливать временной интервал для 
отдельного соединения, но пока она не получила широкого распространения. 

Еще одна проблема, связанная с механизмом контролеров, состоит в том, что 
он не просто обнаруживает «мертвые» соединения, а еще и разрывает их незави- 
симо от того, допускает ли это приложение. 


Пульсация 


Задача проверки наличия соединения, неразрешимая с помощью механизма 
контролеров, легко решается путем реализации аналогичного механизма в самом 
приложении. Оптимальный метод зависит от приложения. Здесь вы можете пол- 
нее оценить гибкость, которая может быть достигнута при реализации на приклад- 
ном уровне. В качестве примеров рассмотрим два крайних случая: 


о клиент и сервер обмениваются сообщениями разных типов, каждое из KOTO- 
рых имеет заголовок, идентифицирующий тип сообщения; 
о приложение передает данные в виде потока байтов без разбиения на записи. 


Первый случай сравнительно несложен. Вводится новый тип сообщения 
MSG, HEARTBEAT. Получив такое сообщение, приложение возвращает ero отправи- 
телю. Такой способ предоставляет большую свободу. Проверять наличие связи 
могут одна или обе стороны, причем только одна действительно посылает конт- 
рольное сообщение-пульс. 

Сначала рассмотрим заголовочный файл (листинг 2.23), который используют 
как клиент, так и сервер. 


Листинг 2.23. Заголовочный файл для реализации механизма пульсации 


heartbeat.h 


1 #1ЕпаеЕ _ HEARTBEAT H . 

2 d&define | HEARTBEAT H . 

3 #define MSG, TYPE1 1 /* Сообщение прикладного уровня. */ 
4 «define MSG TYPE2 2 /* Еще одно. */ 

5 #АеЕ1пе MSG HEARTBEAT 3 /* Сообщение-пульс. */ 

6 typedef struct /* Структура сообщения. */ 

7 {í 

8 u int32 t type; /* MSG TYPEl, ... */ 

9 char data[ 2000 ]; 

10 ) msg t; 
11 £define T1 60 /* Время простоя перед отправкой пульса. */ 
12 #define T2 10 /* Время ожидания ответа. */ 


13 #ералЕ /* _ HEARTBEAT H */ 
heartbeat.h 


3-5 С помощью этих констант определяются различные типы сообщений, 
которыми обмениваются клиент и сервер. Для данного примера нужно 
только сообщение MSG, HEARTBEAT. 
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6-10 


11 


12 


Здесь определяется структура сообщений, которыми обмениваются 
клиент и сервер. Здесь представляет интерес только поле суре. Реаль- 
ное приложение могло бы подстроить эту структуру под свои возмож- 
ности. Подробнее это рассматривается в замечаниях к листингу 2.15 
о смысле типа u, int32, t и об опасности предположений о способе 
упаковки структур. 

Данная константа определяет, сколько времени может простаивать со- 
единение, прежде чем приложение начнет посылать контрольные со- 
общения-пульсы. Здесь произвольно выбрано 60 с, реальное же при- 
ложение должно подобрать значение, наиболее соответствующее его 
потребностям и виду сети. 

Эта константа определяет, сколько времени клиент будет ждать ответа 
на контрольное сообщение. 


В листинге 2.24 приведен текст клиента, который инициирует посылку конт- 
рольных сообщений. Такой выбор абсолютно произволен, в качестве инициатора 
можно было выбрать сервер. 


Листинг 2.24. Клиент, посылающий контрольные сообщения-пульсы 


hb client.c 


1 £&include "etcp.h" 
2 $include "heartbeat.h" 
3 int main( int argc, char **argv ) 


fd set а11Еа; 

fd set геааға; 
msg. t msg; 

struct timeval tv; 


SOCKET s; 

int rc; 

int heartbeats - 0; 

int cnt = sizeof( msg ); 
INIT(); 


S = tcp client( argv[ 1 ], argvi 2 ] ); 
FD ZERO( &allfd ); 
FD SET( s, &allfd ); 
tv.tv sec = ТІ; 
tv.tv usec - 0; 
for ( ;; ) 
{ 
readfd = allfd; 
rc = select( $ + 1, &readfd, NULL, NULL, &tv ); 
XE due) 
error( 1, errno, "ошибка вызова select" ); 
if (rc == 0) /* Произошел тайм-аут. */ 
( 
if ( *-*heartbeats > 3 ) 
error( 1, 0, "соединения HeTMn" ); 
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29 error( 0, 0, "посылаю пульс #%d\n", heartbeats ); 

30 msg.type = htonl( MSG HEARTBEAT ); 

31 rc = send( s, ( char * )&msg, sizeof( msg ), 0); 

32 if (rc < 0) 

33 error( 1, errno, "ошибка вызова Send" ); 

34 tv.tv sec - T2; 

35 continue; 

36 ) 

37 if ( !FD ISSET( s, &readfd ) ) 

38 error( 1, 0, "select вернул некорректный сокет\п" ); 

39 rc = recv( s, ( char * )&msg + sizeof( msg ) - cnt, 

40 cnt, 0 ); 

41 if (rc == Q ) 

42 error( 1, 0, "сервер закончил работу\п" ); 

43 if (ore 0-) 

44 error( 1, errno, "ошибка вызова recv" ); 

45 heartbeats = 0; 

46 tv.tv sec - T1; 

47 cnt -= rc; /* Встроенный readn. */ 

48 if (cnt > 0 ) 

49 continue; 

50 cnt = sizeof( msg ); 

51 /* Обработка сообщения. */ 

52 } 

53 } 

hb client.c 

Инициализация 

13-14 Выполняем стандартную инициализацию и соединяемся с сервером, 
адрес и номер порта которого заданы в командной строке. 

15-16 Задаем маску для системного вызова select, в которой выбран ваш 
сокет. 

17-18 Взводим таймер на T1 секунд. Если за это время не было получено HH- 
какого сообщения, To select вернет управление с индикацией cpa6a- 
тывания таймера. 

21-22 Устанавливаем маску, выбирающую сокет, из которого читаем, после 
чего система блокирует программу в вызове select, пока не поступят 
данные либо не сработает таймер. 

Обработка тайм-аута 

27-28 Если послано подряд более трех контрольных пульсов и не получено 
ответа, то считается, что соединение «мертво». В этом примере просто 
завершаем работу, но реальное приложение могло бы предпринять 60- 
лее осмысленные действия. 

29-33 Если максимальное число последовательных контрольных пульсов не 
достигнуто, посылается новый пульс. 

34-35 Устанавливаем таймер на Т2 секунд. Если за это время не получен от- 


вет, то либо отправляется новый пульс, либо соединение признается 
«мертвым» в зависимости от значения переменной heartbeats. 
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Обработка сообщения 
37-38 Если select вернул сокет, отличный OT соединенного с сервером, TO 


39-40 


41-44 
45-46 


47-50 


завершаемся с сообщением о фатальной ошибке, 

Вызываем recv для чтения одного сообщения. Эти строки, а также сле- 
дующий за ними код, изменяющий значение переменной cnt, — не что 
иное, как встроенная версия функции readn. Она не может быть вы- 
звана напрямую, поскольку заблокировала бы весь процесс на неопре- 
деленное время, нарушив тем самым работу механизма пульсации. 
Если получаем признак конца файла или ошибку чтения, выводим ди- 
агностическое сообщение и завершаем сеанс. 

Поскольку только что получен ответ от сервера, сбрасывается счетчик 
пульсов в 0 и переустанавливается таймер на T1 секунд. 

Эти строки завершают встроенный вариант readn. Уменьшаем пере- 
менную cnt на число, равное количеству только что прочитанных байт. 
Если прочитано не все, то следует повторить цикл с вызова select. 
В противном случае заносится B cnt полная длина сообщения и завер- 
шается обработка только что принятого сообщения. 


Листинг 2.25 содержит текст сервера для этого примера. Здесь предполагается 
что сервер также будет следить за состоянием соединения, но это не обязательно. 


Листинг 2.25. Сервер, отвечающий на контрольные сообщения-пульсы 


о Јо олњ QJ N н 


hb server.c 


#include "etcp.h" 
#іпс1чае "heartbeat.h" 


int main( int argc, char **argv ) 


( 


fd set allfd; 

fd set readfd; 

msg t msg; 

struct timeval tv; 

SOCKET s; 

SOCKET s1; 

int rc; 

int missed heartbeats - 0; 
int cnt - sizeof( msg ); 


INIT(); 
S = tcp server( NULL, argví[ 1 ] ); 
sl - accept( s, NULL, NULL ); 
1f ( lisvalidsock( s1 ) ) 
error( 1, errno, "ошибка вызова accept" ); 
tv.tv sec = T1 + T2; 
tv.tv usec - 0; 
FD ZERO( &allfd ); 
FD SET( s1, &allfd ); 
for ( xf) 


( 
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25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 


57 
58 
59 


60 
61 
62 
63 
64 


65 
66 
67 
68 
69 
70 
71 


} 


readfd = allfd; 


rc 
if 


if 
( 


( 


select( s] * 1, &readfd, NULL, NULL, &tv 
rc « 0) 


error( 1, errno, "ошибка вызова Select" ); 


( 


if 


rc == 0 ) /* Произошел тайм-аут. */ 


( ++missed_heartbeats > 3 ) 
error( 1, 0, "соединение умерло\п" ); 


error( 0, 0, "пропущен пульс #%4\п", 


missed heartbeats ); 


tv.tv sec = T2; 
continue; 


ys 


if ( !FD ISSET( s1, &readfd ) ) 
error( 1, 0, "select вернул некорректный сокет\п" ); 
rc = гесу( sl, ( char * )&msg + sizeof( msg ) - cnt, 
cnt, 0 ); 
if (rc == 0 ) 
error( 1, 0, "клиент завершил работу\п" ); 
if (rc<0) 
error( 1, errno, "ошибка вызова recv" ); 
missed_heartbeats = 0; 
tv.tv_sec = T1 + T2; 
cnt -= гс; /* Встроенный readn. */ 
if (cnt > 0 ) 
continue; 
cnt sizeof( msg ); 
switch ( ntohl( msg.type ) ) 
( 
case MSG TYPEI1 
/* Обработать сообщение типа ТУРЕ1. */ 
break; 
case MSG TYPE2 
/* Обработать сообщение типа TYPE2. */ 
break; 
case MSG HEARTBEAT : 
rc = send( s1, ( char * )&msg, sizeof( msg ), 0); 
if (rc < 0) 
error( 1, errno, "ошибка вызова send" ); 
break; 
default 
error( 1, 0, "неизвестный тип сообщения ($d)Mn", 


) 


ntohl( msg.type ) ); 


EXIT( 0 3 


} 


hb_server.c 
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Инициализация 


14-18 


19-20 


21-22 


25-28 


Выполняем стандартную инициализацию и принимаем соединение от 
клиента. 

Взводим таймер на Т1 + Т2 секунд. Поскольку клиент посылает пульс 
после T1 секунд неактивности, следует подождать немного больше — 
на Т2 секунд. 

Инициализируем маску для select, указывая в ней соединенный со- 
кет, из которого происходит чтение. 

Вызываем select и проверяем возвращенное значение. 


Обработка тайм-аута 


31-32 


35 


Если пропущено более трех пульсов подряд, то соединение считается 
«мертвым» — работа завершается. Как и клиент, реальный сервер мог 
бы предпринять в этом случае более осмысленные действия. 

Взводим таймер на Т2 секунд. К этому моменту клиент должен был 
бы посылать пульсы каждые Т2 секунд, так что если за это время ни- 
чего не получено, то необходимо увеличить счетчик пропущенных 
пульсов. 


Обработка сообщения 


38-39 
40-41 
42-45 


46-47 


48-51 
60-64 


Производим ту же проверку корректности сокета, что и в клиенте. 
Как и в клиенте, встраиваем код функции readn. 

Если гесу возвращает признак конца файла или код ошибки, то печа- 
таем диагностическое сообщение и выходим. 

Поскольку только что получено сообщение от клиента, соединение все 
еще живо, так что сбрасываем счетчик пропущенных пульсов в нуль 
и взводим таймер на T1 + T2 секунд. 

Этот код, такой же, как в клиенте, завершает встроенную версию readn. 
Если это сообщение-пульс, то возвращаем его клиенту. Когда кли- 
ент получит сообщение, обе стороны будут знать, что соединение 
еще есть. 


Для тестирования этих программ запустим программу hb, server на машине 
sparc, а программу hb client – на машине bsd. После того как клиент соеди- 
нится с сервером, отключим зрагс от сети. Вот что при этом будет напечатано: 


Sparc: $ hb server 9000 bsd: $ hb, client sparc 9000 
hb server: пропущен пульс #1 hb client: посылаю пульс #1 
hb server: пропущен пульс #2 hb client: посылаю пульс #2 
hb server: пропущен пульс #3 hb client: посылаю пульс #3 
hb server: соединения нет hb client: соединения нет 
Sparc: $ bsd: $ 


Еще один пример пульсации 


Использованная в предыдущем примере модель не совсем пригодна в ситуации, 
когда одна сторона посылает другой поток данных, не разбитый на сообщения. 
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Проблема в том, что посланный пульс оказывается частью потока, поэтому его 
придется явно выискивать и, возможно, даже экранировать (совет 6). Чтобы из- 
бежать сложностей, следует воспользоваться другим подходом. 

Идея в том, чтобы использовать для контрольных пульсов отдельное соедине- 
ние. На первый взгляд, кажется странной возможность контролировать одно со- 
единение с помощью другого. Но помните, что делается попытка обнаружить крах 
хоста на другом конце или разрыв в сети. Если это случится, то пострадают оба 
соединения. Задачу можно решить несколькими способами. Традиционный спо- 
соб — создать отдельный поток выполнения (thread) для управления пульсацией. 
Можно также применить универсальный механизм отсчета времени, который раз- 
работан в совете 20. Однако, чтобы не вдаваться в различия между АР] потоков на 
платформе Win32 и библиотекой PThreads s UNIX, модифицируем написанный 
для предыдущего примера код с использованием системного вызова select. 

Новые версии клиента и сервера очень похожи на исходные. Основное разли- 
чие состоит в логике работы select, который теперь должен следить за двумя CO- 
кетами, а также в дополнительном коде для инициализации еще одного соединения. 
После соединения клиента с сервером, клиент посылаетему номер порта, по которо- 
му отслеживается пульсация сервера. Это напоминает то, что делает ЕТР-сервер, 
устанавливая соединение для обмена данными с клиентом. 


Примечание Может возникнуть проблема, если для преобразования частных 
сетевых адресов в открытые используется механизм МАТ (со- 
вет 3). В отличие от ситуации с ЕТР программное обеспечение 
МАТ не имеет информации, что нужно подменить указанный 
номер порта преобразованным. В таком случае самый простой 
путь — выделить приложению второй хорошо известный порт. 


Начнем с логики инициализации и установления соединения на стороне кли- 
ента (листинг 2.26). 


Листинг 2.26. Код инициализации и установления соединения на стороне клиента 


hb client2.c 
d&include "etcp.h" 
d$include "heartbeat.h" 


int main( int argc, char **argv ) 
{ 

fd set allfd; 

fd set геааға; 

char msg[ 1024 ]; 

struct timeval tv; 

struct sockaddr. in hblisten; 

SOCKET sdata; 

SOCKET shb; 

SOCKET slisten; 

int rc; 

int hblistenlen = sizeof( hblisten ); 
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15 int heartbeats = 0; 
16 int maxfdl; 
17 char hbmsg[ 1 ]; 


18 INIT(); 

19 slisten = tcp server( NULL, "0" ); 

20 rc = getsockname( slisten, ( struct sockaddr * )&hblisten, 
21 &hblistenlen ); 

22 if (rce) 

23 error( 1, errno, "ошибка вызова getsockname" ); 

24 sdata = tcp client( argv[ 1 ], argv[ 2 ] ); 

25 rc = send( sdata, ( char * )&hblisten.sin port, 

26 sizeof( hblisten.sin port ), 0 ); 

27 if (тс «0) 

28 error( 1, errno, "ошибка при посылке номера порта" ); 
29 shb = accept( slisten, NULL, NULL ); 

30 if ( !isvalidsock( shb ) ) 

31 error( 1, errno, "ошибка вызова accept" ); 


32 FD ZERO( &allfd ); 

33 FD SET( sdata, &allfd ); 

34 FD SET( shb, &allfd ); 

35 maxfdl = ( sdata > shb ? sdata: shb ) + 1; 


36 tv 
37 tv 


.tv. sec = ТІ; 
.tv usec = 0; 
hb client2.c 


Инициализация и соединение 


19-23 


24-28 


29-31 


32-37 


Вызываем функцию tcp, server с номером порта 0, таким образом за- 
ставляя ядро выделить эфемерный порт (совет 18). Затем вызываем 
getsockname, чтобы узнать номер этого порта. Это делается потому, что 
с данным сервером ассоциирован только один хорошо известный порт. 
Соединяемся с сервером и посылаем ему номер порта, с которым он 
должен установить соединение для посылки сообщений-пульсов. 
Вызов accept блокирует программу до тех пор, пока сервер не устано- 
вит соединение для пульсации. В промышленной программе, наверное, 
стоило бы для этого вызова взвести таймер, чтобы программа не «за- 
висла», если сервер не установит соединения. Можно также проверить, 
что соединение для пульсации определил именно тот сервер, который 
запрашивался в строке 24. 

Инициализируем маски для select и взводим таймер. 


Оставшийся код клиента показан в листинге 2.27. Здесь вы видите обработку 
содержательных сообщений и контрольных пульсов. 


Листинг 2.27. Обработка сообщений клиентом 


38 for 
39 { 
40 


hb client2.c 
C or 


readfd = allfd; 
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41 rc = select( maxfdl1, &readfd, NULL, NULL, &tv ); 
42 if (rc «0) 


43 error( 1, errno, "ошибка вызова Select" ); 

44 if ( гс == 0) /* Произошел тайм-аут. */ 

45 { 

46 if ( ++heartbeats > 3 ) 

47 error( 1, 0, "соединения HeTMn" ); 

48 error( 0, 0, "посылаю пульс #%А\п", heartbeats ); 
49 rc - send( shb, "", 1, 0 ); 

50 if (rc < 0) 

51 error( 1, errno, "ошибка вызова send" ); 

52 tv.tv sec - T2; 

53 continue; 

54 } 

55 if ( FD ISSET( shb, &readfd ) ) 

56 ( 

57 rc = recv( shb, hbmsg, 1, 0); 

58 if (тс == 0) 

59 error( 1, 0, "сервер закончил работу (shb)WMn" ); 
60 if (rc « 0) 

61 error( 1, errno, "ошибка вызова recv для сокета shb" 
); 

62 } 

63 if ( FD_ISSET( sdata, &readfd ) ) 

64 { 

65 гс = гесу( sdata, msg, sizeof( msg ), 0 ); 

66 if (rec == 0) 

67 error( 1, 0, "сервер закончил работу (sdata)'Nn" ); 
68 if (тс « 0) 

69 error( 1, errno, "ошибка вызова гесу" ); 

70 /* Обработка данных. */ 

71 ) 

72 heartbeats = 0; 

73 tv.tv sec = T1; 

74 } 

75 } 


hb client2.c 


Обработка данных M пульсов 


40-43 Вызываем функцию select и проверяем код возврата. 

44-54 Таймаут обрабатывается так же, как в листинге 2.24, только пульсы 
посылаются через сокет shb. 

25-62 Если через сокет shb пришли данные, читаем их, но ничего не делаем. 

63-71 Если данные пришли через сокет sdata, читаем столько, сколько CMO- 
жем, и обрабатываем. Обратите внимание, что теперь производится 
работа не с сообщениями фиксированной длины. Поэтому читается не 
больше, чем помещается в буфер. Если данных меньше длины буфера, 
вызов recV вернет все, что есть, но не заблокирует программу. Если 
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данных больше, то из сокета еще можно читать. Поэтому следующий 
вызов select немедленно вернет управление, и можно будет обрабо- 
тать очередную порцию данных. 

72-73 Поскольку только что пришло сообщение от сервера, сбрасываем пере- 
менную heartbeats в 0 и снова взводим таймер. 


И взаключение рассмотрим код сервера для этого примера (листинг 2.28). Как 
и код клиента, он почти совпадает с исходным сервером (листинг 2.25) за тем ис- 
ключением, что устанавливает два соединения и работает с двумя сокетами. 


Листинг 2.28. Код инициализации и установления соединения на стороне сервера 


hb server2.c 


1 £&include "etcp.h" 
2 fstnclude "heartbeat.h" 
3 int main( int argc, char **argv ) 
4 { 
5 fd set allfd; 
6 fd set геааға; 
7 char msg{ 1024 ]; 
8 struct sockaddr, in peer; 
9 struct timeval tv; 
10 SOCKET s; 
11 SOCKET sdata; 
12 SOCKET shb; 
13 int rc; 
14 int maxfd1; 
15 int missed, heartbeats - 0; 
16 int peerlen = sizeof( peer ); 
17 char hbmsg( 1 ]; 
18 INIT(); 
19 S = tcp server( NULL, argv[ 1 ] ): 
20 sdata = accept( s, ( struct sockaddr * )&peer, 
21 &peerlen ); 
22 if ( tisvalidsock( sdata ) ) 
23 error( 1, errno, "accept failed" ); 
24 rc - readn( sdata, ( char * )&peer.sin port, 
25 sizeof( peer.sin port ) ); 
26 Ета < D--) 
27 error( 1, errno, "ошибка при чтении номера порта" ); 
28 shb = socket( PF INET, SOCK STREAM, 0 ); 
29 if ( lisvalidsock( shb ) ) 
30 error( 1, errno, "ошибка при создании сокета shb" ); 
31 rc = connect( shb, ( struct sockaddr * )&peer, peerlen }; 
32 if ( re ) 
33 error( 1, errno, "ошибка вызова connect для сокета shb" ); 
34 tv.tv sec = T1 + T2; 
35 tv.tv usec = 0; 
36 FD ZERO( &allfd ); 


ТСР не выполняет опрос соединения НЕТ | |109 


37 FD SET( sdata, &allfd ); 
38 FD SET( shb, &allfd ); 
39 maxfdl = ( sdata > shb ? sdata : shb ) + 1; 
hb server2.c 


Инициализация и соединение 


19-23 Слушаем и принимаем соединения от клиента. Кроме того, сохраняем 
адрес клиента в переменной peer, чтобы знать, с кем устанавливать CO- 
единение для пульсации. 

24-27 Читаем номер порта, который клиент прослушивает в ожидании соеди- 
нения для пульсации. Считываем его непосредственно в структуру peer. 
О преобразовании порядка байтов с помощью htons или ntohs беспо- 
коиться не надо, так как порт уже пришел в сетевом порядке. В таком 
виде его и надо сохранить в реек. 

28-33 Получив сокет shb, устанавливаем соединение для пульсации. 

34-39 Взводим таймер и инициализируем маски для select. 


Оставшаяся часть сервера представлена в листинге 2.29. 


Листинг 2.29. Обработка сообщений сервером 


hb server2.c 
40 for 4 ;; ) 
41 { 
42 readfd = allfd; 
43 rc = select( пахЁЯ1, &readfd, NULL, NULL, &tv ); 
44 if (тс «0 ) 


45 error( 1, errno, "ошибка вызова Select" ); 

46 if ( гс == 0) /* Произошел тайм-аут. */ 

47 { 

48 if ( **missed heartbeats > 3 ) 

49 error( 1, 0, "соединения нет\п" ); 

50 error( 0, 0, "пропущен пульс #%4\п", 

51 missed heartbeats ); 

52 tv.tv sec - T2; 

53 continue; 

54 ) 

55 if ( FD ISSET( shb, &readfd ) ) 

56 { 

57 гс = recv( shb, hbmsg, 1, 0 ); 

58 if ( re == 0 ) 

59 error( 1, 0, "клиент завершил работу\п" }; 
60 if (rc<0) 

61 error( 1, errno, "ошибка вызова гесу для сокета shb" ); 
62 rc = send( shb, hbmsg, 1, 0); 

63 if (re « 0) 

64 error( 1, errno, "ошибка вызова send для сокета shb" ); 
65 ) 


66 if ( FD ISSET( sdata, &readfd ) ) 
67 { 


о Основы 


68 rc = recv( sdata, msg, sizeof( msg ), 0); 
69 if (тс == 0 ) 

70 error( 1, 0, "клиент заверщил работу\п" ); 
71 if (rec « 0) 

72 error( 1, errno, "ошибка вызова recv" ); 
73 /* Обработка данных. */ 

74 } 

75 missed heartbeats = 0; 

76 tv.tv sec = Т1 + Т2; 

77 } 

78 EXIT( O ); 

79 ) 


hb server2.c 

42-45 Как и в ситуации с клиентом, вызываем select и проверяем возвра- 
щаемое значение. 

46-53 Обработка тайм-аута такая же, как и в первом примере сервера в лис- 
тинге 2.25. 

55-65 Если в сокете shb есть данные для чтения, то читаем однобайтовый 
пульс и возвращаем его клиенту. 

66-74 Если что-то поступило по соединению для передачи данных, читаем 
и обрабатываем данные, проверяя ошибки и признак конца файла. 

75-76 Поскольку только что получены данные от клиента, соединение все 
еще живо, поэтому сбрасываем в нуль счетчик пропущенных пульсов 
и Переустанавливаем таймер. 


Если запустить клиента и сервер и имитировать сбой в сети, отсоединив один 
из хостов, То получим те же результаты, что при запуске hb. serverH hb client. 


Резюме 


Хотя ТСР и не предоставляет средств для немедленного уведомления клиента 
о потере связи, тем не менее несложно самостоятельно встроить такой механизм 
в приложение. Здесь рассмотрены две модели реализации контрольных сообще- 
ний-пульсов. На первый взгляд, это может показаться избыточным, но одна мо- 
дель не подходит для всех случаев. 

Первый способ применяется, когда приложения обмениваются между собой 
сообщениями, содержащими поле идентификатора типа. В этом случае все очень 
просто: достаточно добавить еще один тип для сообщений-пульсов. «Родители» 
могут спокойно работать — их «дети» под надежным присмотром. 

Второй способ применим в ситуации, когда приложения обмениваются пото- 
ком байтов без явно выраженных границ сообщений. В качестве примера можно 
назвать передачу последовательности нажатий клавиш. В данном примере исполь- 
зовано отдельное соединение для приема и передачи пульсов. Разумеется, тот же 
метод можно было бы применить и в первом случае, но он несколько сложнее, чем 
простое добавление нового типа сообщения. 

В книге «UNIX Network Programming» [Stevens 1998] описан еще один метод 
организации пульсации с помощью механизма срочных данных, имеющегося 


Некорректное поведение партнера MILII | | m 


в ГСР. Это лишний раз демонстрирует, какие разнообразные возможности име- 
ются в распоряжении прикладного программиста для организации уведомления 
приложения о потере связи. 

Наконец, следует напомнить, что хотя было сказано только о протоколе ТСР, 
то же самое верно и в отношении UDP, Представим сервер, который посылает 
широковещательные сообщения нескольким клиентам в локальной сети или орга- 
низует групповое вещание на глобальную сеть. Поскольку соединения нет, клиенты 
не имеют информации о крахе сервера, хоста или сбое в сети. Если в датаграммах 
есть поле типа, то серверу нужно лишь определить тип для датаграммы-пульса 
и посылать ее, когда в сети какое-то время не было других сообщений. Вместо этого 
OH MOT бы рассылать широковещательные датаграммы на отдельный порт, который 
клиенты прослушивают. 


Совет 11. Будьте готовы к некорректному 
поведению партнера 


Часто при написании сетевых приложений не учитывают возможность возник- 
новения ошибки, считая ее маловероятной. В связи с этим ниже приведена выдерж- 
ка из требований к хостам, содержащихся в КЕС 1122 [Braden 1989, стр. 12]: «Про- 
грамма должна обрабатывать любую возможную ошибку, как бы маловероятна она 
ни была; рано или поздно придет пакет именно с такой комбинацией ошибок иат- 
рибутов, и если программа не готова к этому, то неминуем хаос. Правильнее всего 
предположить, что сеть насыщена злонамеренными агентами, которые посылают 
пакеты, специально подобранные так, чтобы вызвать максимально разрушитель- 
ный эффект. Необходимо думать о том, как защититься, хотя надо признать, что 
наиболее серьезные проблемы в сети Internet были вызваны непредвиденными Me- 
ханизмами, сработавшими в результате сочетания крайне маловероятных событий. 
Никакой злоумышленник не додумался бы до такого!» 

Сегодня этот совет более актуален, чем во время написания. Появилось мно- 
жество реализаций ТСР и некоторые из них содержат грубые ошибки. К тому 
же все больше программистов разрабатывают сетевые приложения, но далеко 
не у всех есть опыт работы в этой области. 

Однако самый серьезный фактор — это лавинообразный рост числа подклю- 
ченных к Internet персональных компьютеров. Ранее можно было предполагать, 
что у пользователей есть хотя бы минимальная техническая подготовка, они пони- 
мали, к каким последствиям приведет, скажем, выключение компьютера без пред- 
варительного завершения сетевого приложения. Теперь это не так. 

Поэтому особенно важно практиковать защитное программирование и пред- 
видеть все действия, которые может предпринять хост на другом конце, какими 
бы маловероятными они ни казались. Эта тема уже затрагивалась в совете 9 при 
обсуждении потенциальных ошибок при работе с ТСР, а также в совете 10, где 
речь шла об обнаружении потери связи. В этом разделе будет рассмотрено, какие 
действия вашего партнера могут нанести ущерб. Главное — не думайте, что он бу- 
дет следовать прикладному протоколу, даже если обе стороны протокола реализо- 
вывали вы сами. 
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Проверка завершения работы клиента 


Предположим, что клиент извещает о желании завершить работу, посылая 
серверу запрос из одной строки, в которой есть только слово quit. Допустим да- 
лее, что сервер читает строки из входного потока с помощью функции readline 
(ее текст приведен в листинге 2.32), которая была описана в совете 9. Что про- 
изойдет, если клиент завершится (аварийно или нормально) раньше, чем пошлет 
команду quit? ТСР на стороне клиента отправит сегмент FIN, после uero опера- 
ция чтения на сервере вернет признак конца файла. Конечно, это просто обнару- 
жить, только сервер должен обязательно это сделать. Легко представить себе та- 
кой код, предполагая правильное поведение клиента: 


for bu 
( 
if ( readline( s, buf, sizeof( buf ) ) < 0 ) 
error( 1, errno, "ошибка вызова readline" ); 
if ( strcmp( buf, "quitWAn" ) == 0) 
/* Выполнить функцию завершения клиента. */ 
е1зе 
/* Обработать запрос. */ 


} 


Хотя код выглядит правильным, он не работает, поскольку будет повторно об- 
рабатывать последний запрос, если клиент завершился, не послав команду quit. 

Предположим, что вы увидели ошибку в предыдущем фрагменте (или нашли 
ее после долгих часов отладки) и изменили код так, чтобы явно обнаруживался 
признак конца файла: 


for ( x) 
{ 
rc = readline( s, buf, sizeof( buf ) ); 
Lf (rc<o0) 
error( 1, errno, "ошибка вызова readline" ); 
if (rc == 0 || strcmp( buf, "quitWn" ) == 0) 
/* Выполнить функцию завершения клиента. */ 
else 
/* Обработать запрос. */ 


) 


И этот код тоже неправилен, так как в нем He учитывается случай, когда хост 
клиента «падает» до того, как клиент послал команду quit или завершил работу. 
В этом месте легко принять неверное решение, даже осознавая проблему. Для про- 
верки краха клиентского хоста надо ассоциировать таймер с вызовом readline. 
Потребуется примерно в два раза больше кода, если нужно организовать обработ- 
ку «безвременной кончины» клиента. Представив себе, сколько придется писать, 
вы решаете, что шансов «грохнуться» хосту клиента мало. 

Но проблема в том, что хосту клиента и необязательно завершаться. Если это 
ПК, то пользователю достаточно выключить его, не выйдя из программы. А это 
очень легко, поскольку клиент мог исполняться в свернутом окне или в окне, 
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закрытом другими, так что пользователь про него, вероятно, забыл. Есть и другие 
возможности. Если соединение между хостами установлено с помощью модема 
на клиентском конце (так сегодня выполняется большинство подключений к In- 
ternet), то пользователь может просто выключить модем. Шум в линии также мо- 
жет привести к обрыву соединения. И все это с точки зрения сервера неотличимо 
от краха хоста клиента. 


Примечание При некоторых обстоятельствах ошибку, связанную с модемом, 
можно исправить, повторно набрав номер (помните, что ТСР 
способен восстанавливаться после временных сбоев в сети), но 
зачастую ІР-адреса обоих оконечных абонентов назначаются 
динамически сервис-провайдером при установлении соединения. 
В таком случае маловероятно, что будет задан тот же адрес, 
и поэтому клиент не сможет оживить соединение. 


Для обнаружения потери связи с клиентом необязательно реализовывать 
пульсацию, как это делалось в совете 10. Нужно всего лишь установить тайм-аут 
для операции чтения. Тогда, если от клиента в течение определенного времени не 
поступает запросов, то сервер может предположить, что клиента больше нет, и ра- 
зорвать соединение. Так поступают многие ЕТР-серверы. Это легко сделать, либо 
явно установив таймер, либо воспользовавшись возможностями системного вызо- 
ва select, как было сделано при реализации пульсации. 

Если вы хотите, чтобы сервер не «зависал» навечно, то можете воспользовать- 
ся механизмом контролеров для разрыва соединения по истечении контрольного 
тайм-аута. В листинге 2.30 приведен простой ТСР-сервер, который принимает со- 
общение от клиента, читает из сокета и пишет результат на стандартный вывод. 
Чтобы сервер не «завис», следует задать для сокета опцию SO, KEEPALIVE с NOMO- 
щью вызова set sockopt. Четвертый аргумент setsockopt должен указывать на 
ненулевое целое число, если надо активировать посылку контролеров, или на ну- 
левое целое, чтобы ее отменить. 

Запустите этот сервер на машине bsd, а на другой машине – программу telnet 
в качестве клиента. Соединитесь с сервером, отправьте ему строку «hello», чтобы 
соединение точно установилось, а затем отключите клиентскую систему от сети. 
Сервер напечатает следующее: 


bsd: $ keep 9000 
hello 
Клиент отключился от сети. 
Спустя 2 4 11 мин 15 c. 
Кеер: ошибка вызова recv: Operation timed out (60) 
bsd: $ 


Как и следовало ожидать, TCP на машине bsd разорвал соединение и вернул 
серверу код ошибки ETIMEDOUT. В этот момент сервер завершает работу и осво- 
бождает все ресурсы. 
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Листинг 2.30. Сервер, использующий механизм контролеров 


keep.c 
1 £include "etcp.nh" 
2 int main( int argc, char **argv ) 
3 t 
4 SOCKET s; 
5 SOCKET s1; 
6 int on = 1; 
7 int rc; 
8 char риЁ[ 128 ]; 
9 INIT(); 
10 S = tcp server( NULL, argv[ 1 ] ); 
11 $1 = accept( s, NULL, NULD ); 
12 if ( !isvalidsock( 51 ) } 
13 error( 1, errno, "ошибка вызова acceptAn" ); 
14 if ( setsockopt( s1, SOL SOCKET, SO KEEPALIVE, 
15 ( char * )&on, sizeof( on ) ) ) 
16 error( 1, errno, "ошибка вызова setsockopt" ); 
17 for ( ;; ) 
18 { 
19 rc = readline( 51, buf, sizeof( buf ) ); 
20 VI 6 geo ok D 
21 error( 1, 0, "другой конец отключился\п" ); 
22 if ( rc<0) 
23 error( 1, errno, "ошибка вызова гесу" }; 
24 write( 1, buf, rc ); 
25 } 
26 } 
keep.c 


Проверка корректности входной информации 


Чго бы вы ни программировали, не думайте, что приложение будет получать 
только те данные, на которые рассчитывает. Пренебрежение этим принципом ~ 
при чер отсутсгвия защитного программирования. Хочется надеяться, что профес- 
сиональный нрограммист, разрабатывающий коммерческую программу, всегда ему 
следует. Однако часто это правило игнорируют. В работе [Miller et al. 1995] опи- 
сывается, как авторы генерировали случайный набор входных данных и подавали 
его на вход всевозможных стандартных утилит UNIX от разных производителей. 
При этом им удалось «сломать» (с дампом памяти) или «подвесить» (в бесконеч- 
ном цикле) от 6 до 43% тестируемых программ (в зависимости от производителя). 
В семи исследованных коммерческих системах частота отказов составила 23%. 

Вывод ясен: если такие результаты получены при тестировании зрелых про- 
грамм, когорые принято считать программами «промышленного качества», то тем 
более необходимо защищаться и подвергать сомнению все места в программе, где 
неожиданные входные данные могут привести к нежелательным результатам. Рас- 
смотрим несколько примеров, когда неожиданные данные оказываются источни- 
ком ошибок. 
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Две самые распространенные причины краха приложений - это переполнение 
буфера и сбитые указатели. В вышеупомянутом исследовании именно эти две 
ошибки послужили причиной большинства сбоев. Можно сказать, что в сетевых 
программах переполнение буфера должно быть редким явлением, так как при об- 
ращении к системным вызовам, выполняющим чтение (read, гесу, recvfrom, 
readv и readmsg), всегда необходимо указывать размер буфера. Ho вы увидите 
далее, как легко допустить такую ошибку. (Это рассмотрено в замечании к строке 42 
программы shutdown.c в совете 16.) 

Чтобы понять, как это происходит, разработаем функцию readline, исполь- 
зовавшуюся в совете 9. Поставленная задача — написать функцию, которая счи- 
тывает из сокета в буфер одну строку, заканчивающуюся символом новой строки, 
и дописывает в конец двоичный нуль. На начало буфера указывает параметр buf. 
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#include "etcp.h" 
int readline( SOCKET s, char *buf, size t len ); 


Возвращаемое значение: число прочитанных байтов или —1 в случае ошибки. 
Первая попытка реализации, которую надо отбросить сразу, похожа на следу- 
ЮЩИЙ KOJ: 


while ( recv( fd, , &c, 1, 0) == 1) 
( 
*bufptr++ = c; 
if ( с == "An" ) 
break; 


) 


/* Проверка ошибок, добавление завершающего нуля M T.H. */ 
Прежде всего, многократные вызовы recv совсем неэффективны, поскольку 
при каждом вызове нужно два переключения — в режим ядра и обратно. 


Прамечание Но иногда приходится писать и такой код — смотрите, напри- 
мер, функцию readcrlf в листинге 3.10. 


Важнее, однако, то, что нет контроля переполнения буфера. 
Чтобы понять, как аналогичная ошибка может вкрасться и в более рациональ- 
ную реализацию, следует рассмотреть такой фрагмент: 


static char *bp; 
static int cnt = 0; 
static char b[ 1500 ]; 


char c; 
for ( 7) 
{ 
if (cnt-- <= 0) 
{ 
cnt = recv( fd, b, sizeof( b ), 0 ); 


if (cnt < 0 ) 
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return -1; 


if (cnt == 0) 
return 0; 
рр = b; 


: = *рр++; 
*bufptr++ = c; 
if ( c == "\n") 
{ 
*bufptr = "X0"; 
break; 


} 


В этой реализации нет неэффективности первого решения. Теперь считывает- 
ся большой блок данных в промежуточный буфер, а затем по одному копируются 
байты в окончательный буфер; по ходу производится поиск символа новой стро- 
ки. Но при этом в коде присутствует та же ошибка, что и раньше. Не проверяется 
переполнение буфера, на который указывает переменная bufptr. Можно было бы 
и не писать универсальную функцию чтения строки; такой код — вместе c ошиб- 
кой — легко мог бы быть частью какой-то большей функции. 

А теперь напишем настоящую реализацию (листинг 2.31). 


Листинг 2.31. Неправильная реализация readline 


readline.c 
1 int readline( SOCKET fd, char *bufptr, size t len ) 
2 { 
3 char *bufx = bufptr; 
4 static char *bp; 
5 statıc int cnt = 0; 
6 static char b[ 1500 ]; 
7 
8 


char с; 

while ( len -- > 0 ) 
9 ( 
10 if ( cnt -- <= 0 ) 
11 ( 
12 cnt = recv( fd, b, sizeof( b ), 0 ); 
13 if ( cnt < 0 ) 
14 return -1; 
15 if ( cnt == 0 ) 
16 return 0; 
17 bp = b: 
18 ) 
19 с = *рр++; 
20 *bufptrt** = c; 
21 if ( c == "\n" ) 
22 ( 


23 *butptr = "\0"; 
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24 return bufptr - bufx; 
25 } 

26 } 

27 set errno( EMSGSIZE ); 

28 return -1; 

29 ) 


readline.c 


Ha первый взгляд, все хорошо. Размер буфера передается readline и во внеш- 
нем цикле проверяется, не превышен ли он. Если размер превышен, то перемен- 
ной errno присваивается значение EMSGSIZE и возвращается -1. 

Чтобы понять, в чем ошибка, представьте, что функция вызывается так: 


rc = readline( s, buffer, 10 ); 
и при этом из сокета читается строка 
123456789«n1» 


Когда в c записывается символ новой строки, значение len равно нулю. Это 
означает, что данный байт последний из тех, что готовы принять. В строке 20 поме- 
щаете символ новой строки в буфер и продвигаете указатель bufptr за конец буфе- 
ра. Ошибка возникает в строке 23, где записывается нулевой байт за границу буфера. 

Заметим, что похожая ошибка имеет место и во внутреннем цикле. Чтобы уви- 
деть ее, представьте, что при входе в функцию readline значение cnt равно нулю 
и recv возвращает один байт. Что происходит дальше? Можно назвать это «опус- 
тошением» (underflow) буфера. 

Этот пример показывает, как легко допустить ошибки, связанные с переполне- 
нием буфера, даже предполагая, что все контролируется. В листинге 2.32 приведе- 
на окончательная, правильная версия readline. 


Листинг 2.32. Окончательная версия readline 


readline.c 
int readline( SOCKET fd, char *bufptr, size t len ) 
( 
char *bufx = bufptr; 
static char *bp; 
static int cnt = 0; 
Static char b[ 1500 }; 


char с; 
while ( --len > 0 ) 
( 
if ( --cnt <= 0 ) 
( 
cnt = recv( fd, b, sizeof( b ), 0 ); 
if (cnt < 0 ) 


{ 
if ( errno == EINTR ) 
{ 
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17 1еп++; /* Уменьшим на 1 в заголовке while. */ 
18 continue; 

19 ) 

20 return -1; 

21 ) 

22 if ( cnt == 0 ) 

23 return 0; 

24 bp = b; 

25 } 

26 с = *рр++; 

27 *bufptrt* = c; 

28 if ( c == "\n" ) 

29 { 

30 *bufptr = "XO"; 

31 return bufptr - bufx; 
32 ) 

33 ) 

34 set errno( EMSGSIZE ); 
35 return -1; 

36 ) 


readline.c 


Единственная разница между этой и предыдущей версиями B TOM, что умень- 
шаются значения len и cnt до проверки, а не после. Также проверяется, не верну- 
ла ли recv значение EINTR. Если это так, то вызов следует повторить. При умень- 
шении len до использования появляется гарантия, что для нулевого байта всегда 
останется место. А, уменьшая cnt, можно получить некоторую уверенность, что 
данные не будут читаться из пустого буфера. 


Резюме 


Вы всегда должны быть готовы к неожиданным действиям со стороны пользо- 
вателей и хостов на другом конце соединения. В этом разделе рассмотрено два 
примера некорректного поведения другой стороны. Во-первых, нельзя надеяться 
на то, что партнер обязательно сообщит вам о прекращении передачи данных. Во- 
вторых, продемонстрирована важность проверки правильности входных данных 
и разработана функция readline, устойчивая к ошибкам. 


Совет 12. Не думайте, что программа, работающая 
в локальной сети, будет работать и в глобальной 


Многие сетевые приложения разрабатываются и тестируются в локальной 
сети или даже на одной машине. Это просто, удобно и недорого, но при этом могут 
остаться незамеченными некоторые ошибки. 

Несмотря на возможную потерю данных, показанную в совете 7, локальная 
сеть представляет собой среду, в которой датаграммы почти никогда не теряются, 
не задерживаются и практически всегда доставляются в правильном порядке. Од- 
нако из этого не следует делать вывод, что приложение, замечательно работающее 


Работа в локальной и глобальной сетях 
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в локальной сети, будет также хорошо функционировать и в глобальной сети или 
в Internet. Здесь можно столкнуться с проблемами двух типов: 


о производительность глобальной сети оказывается недостаточной из-за до- 
полнительных сетевых задержек; 
о некорректный код, работавший в локальной сети, отказывает в глобальной. 


Если вам встречается проблема первого типа, то, скорее всего, приложение 
следует перепроектировать. 


Недостаточная производительность 


Чтобы получить представление о такого рода проблемах, изменим программы 
hb server (листинг 2.25) и hb. client (листинг 2.24), задав T1, равным 2c, a T2 — 
1 c (листинг 2.23). Тогда пульс будет посылаться каждые две секунды, и при отсут- 
ствии ответа в течение трех секунд приложение завершится. 

Сначала запустим эти программы в локальной сети. Проработав почти семь 
часов, сервер сообщил о пропуске одного пульса 36 раз, а о пропуске двух пуль- 
сов — один раз. Клиенту пришлось посылать второй пульс 11 из 12139 раз. И кли- 
ент, и сервер работали, пока клиент не остановили вручную. Такие результаты 
типичны для локальной сети. Если не считать редких и небольших задержек, со- 
общения доставляются своевременно. 

А теперь запустим те же программы в Internet. Спустя всего лишь 12 мин кли- 
ент сообщает, что послал три пульса, не получив ответа, и завершает сеанс. Распе- 
чатка выходной информации от клиента, частично представленная ниже, показы- 
вает, как развивались события: 


Sparc: $ hb client 205.184.151.171 9000 

hb client: посылаю пульс: #1 

hb client: посылаю пульс: #2 

hb client: посылаю пульс: #3 

hb client: посылаю пульс: #1 

hb client: посылаю пульс: #2 

hb client: посылаю пульс: #1 
Много строк опущено. 

hb client: посылаю пульс: #1 

hb client: посылаю пульс: #2 

hb client: посылаю пульс: #1 

hb client: посылаю пульс: #2 

hb client: посылаю пульс: #3 

hb client: посылаю пульс: #1 

hb client: посылаю пульс: #2 

hb client: Соединение завершается через 
1 с после последнего пульса. 

Sparc: $ 


В этот раз клиент послал первый пульс 251 раз, а второй - 247 раз. Таким об- 
разом, он почти ни разу не получил вовремя ответ на первый пульс. Десять раз 
клиенту пришлось посылать третий пульс. 
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Сервер также продемонстрировал значительное падение производительнос- 
ти. Тайм-аут при ожидании первого пульса происходил 247 раз, при ожидании 
второго пульса — 5 и при ожидании третьего пульса - 1 раз. 

Этот пример показывает, что приложение, которое прекрасно работает в усло- 
виях локальной сети, может заметно снизить производительность в глобальной. 


Скрытая ошибка 


В качестве примера проблемы второго типа рассмотрим основанное на ТСР 
приложение, занимающееся телеметрией. Здесь сервер каждую секунду принима- 
ет от удаленного датчика пакет с результатами измерений. Пакет может состоять 
из двух или трех целочисленных значений. В примитивной реализации подобного 
сервера мог бы присутствовать такой цикл: 


int pkt[ 3 ]; 
for ( 32 ) 
( 
rc = recv( s, ( char * ) pkt, sizeof( pkt ), 0); 
if ( rc != sizeof( int ) * 2 && rc != sizeof( int ) * 3 ) 
/* Протоколировать ошибку и выйти. */ 
else 


/* Обработать rc / sizeof( int ) значений. */ 


) 


Из совета 6 вы знаете, что этот код некорректен, но попробуем провести про- 
стое моделирование. Напишем сервер (листинг 2.33), в котором реализован толь- 
ко что показанный цикл. 


Листинг 2.33. Моделирование сервера телеметрии 


Ум (е1ещеёту5.с 
d&include "etcp.h" 


1 

2 ddefine TWOINTS ( sizeof( int ) * 2) 

3 tdefine THREEINTS ( sizeof( int ) * 3) 

4 int main( int argc, char **argv ) 

S. d 

6 SOCKET 8; 

7 SOCKET $1; 

8 int rc; 

9 int i = 1; 
10 int pkt[ 3 ]; 

11 INIT(); 

12 S = tcp server( NULL, argv[ 1 ] ); 

13 51 = accept( s, NULL, NULL ); 

14 if ( !isvalidsock( s1 ) ) 

15 error( 1, errno, "ошибка вызова accept" ); 
16 for ( ;; ) 

17 { 

18 rc = recv( sl, ( char * )pkt, sizeof( pkt ), 0); 
19 if ( rc !- TWOINTS && гс != THREEINTS ) 
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20 error( 1, 0, "гесу вернула $dWMn', гс ); 

21 printf( "Пакет %а содержит %d значений в $d байтах\п", 
22 i++, ntohl( pkt[ 0 ] ), rc ); 

23 } 

24 ) 


telemetrys.c 


11-15 В этих строках реализована стандартная инициализация и прием со- 
единения. 

16-23 В данном цикле принимаются данные от клиента. Если получено при чте- 
НИИ He В ТОЧНОСТИ sizeof( int ) * 2 ИЛИ sizeof( int ) * 3 байт, то 
протоколируем ошибку и выходим. В противном случае байты первого 
числа преобразуются в машинный порядок (совет 28), а затем резуль- 
тат и число прочитанных байтов печатаются на stdout. В листинге 2.34 
вы увидите, что клиент помещает число значений в первое число, по- 
сылаемое в пакете. Это поможет разобраться в том, что происходит. 
Здесь не используется это число как «заголовок сообщения», содержа- 
щий его размер (совет 6). 


Для тестирования этого сервера также необходим клиент, который каждую 
секунду посылает пакет целых чисел, имитируя работу удаленного датчика. Текст 
клиента приведен в листинге 2.34. 


Листинг 2.34. Имитация клиента для сервера телеметрии 


telemetryc.c 
1 4$include "etcp.h" 

2 int main( int argc, char **argv ) 

3 x 

4 SOCKET s; 

5 int rc; 

6 int i; 

7 int pkt[ 3 ]; 
8 


INIT(); 

9 S = tcp client( argv[ 1 ], argv[ 2 ] ); 

10 for (1=2;;1=5-1)}} 
11 { 

12 pkt[ 0] = htonl( i ); 
13 rc = send( s, ( char * )pkt, i * sizeof( int ), 0); 
14 if ( re « OQ ) 

15 error( 1, errno, "ошибка вызова send" ); 
16 з1еер( 1 ); 

17 } 

18 } 


telemetryc.c 


8-9 Производим инициализацию и соединяемся с сервером. 

10-17 Каждую секунду посылаем пакет из двух или трех целых чисел. Как 
говорилось выше, первое число в пакете — это количество последую- 
щих чисел (преобразованное в сетевой порядок байтов). 
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Для тестирования модели запустим сервер на машине bsd, а клиента — Ha ма- 
шине sparc. Сервер печатает следующее: 


bsd: $ telemetrys 9000 
Пакет 1 содержит 2 значения в 8 байтах 
Пакет 2 содержит 3 значения в 12 байтах 
Много строк опущено. 
Пакет 22104 содержит 3 значения в 12 байтах 
Пакет 22105 содержит 2 значения в 8 байтах 
Клиент завершил сеанс через 
6 ч 8 мин 15 c. 
telemetrys: гесу вернула 0 
bsd: $ 


Хотя в коде сервера есть очевидная ошибка, oH проработал в локальной сети 
без сбоев более шести часов, после чего моделирование завершили с помощью руч- 
ной остановки клиента. 


Примечание Протокол сервера проверен с помощью сценария, написанного на 
awk — необходимо убедиться, что каждая операция чтения вер- 
нула правильное число байтов. 


Однако при запуске того же сервера через Internet результаты получились COB- 
сем другие. Опять запустим клиента на машине sparc, а сервер — на машине bsd, 
НО на этот раз заставим клиента передавать данные через глобальную сеть, указав 
ему адрес сетевого интерфейса, подключенного к Internet. Как видно из последних 
строк, напечатанных сервером, фатальная ошибка произошла уже через 15 мин. 


Пакет 893 содержит 2 значения в 8 байтах 

Пакет 894 содержит 3 значения в 12 байтах 

Пакет 895 содержит 2 значения в 12 байтах 

Пакет 896 содержит -268436204 значения в 8 байтах 
Пакет 897 содержит 2 значения в 12 байтах 

Пакет 898 содержит -268436204 значения в 8 байтах 
Пакет 899 содержит 2 значения в 12 байтах 

Пакет 900 содержит -268436204 значения в 12 байтах 
telemetrys: гесу вернула 4 

bsd: $ 


Ошибка произошла при обработке пакета 895, когда нужно было прочесть 
8 байт, а прочли 12. На рис. 2.21 представлено, что произошло. 

Числа слева показывают, сколько байтов было в приемном буфере ТСР на сто- 
роне сервера. Числа справа — сколько байтов сервер реально прочитал. Вы види- 
те, что пакеты 893 и 894 доставлены и обработаны, как и ожидалось. Но, когда 
telemetrys вызвал recv для чтения пакета 895, в буфере было 20 байт. 


Примечание Трассировка сетевого трафика, полученная с помощью програм- 
мы tcpdump (совет 34), показывает, что в этот момент были 
потеряны ТСР-сегменты, которыми обменивались два хоста. 
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Вероятно, причиной послужила временная перегрузка сети, из- 
за которой промежуточный маршрутизатор отбросил пакет. 
Перед доставкой пакета 895 клиент telemetryc уже подгото- 
вил пакет 896, и оба были доставлены вместе. 


В пакете 895 было 8 байт, но, поскольку уже пришел пакет 896, сервер прочи- 
тал пакет 895 и первое число из пакета 896. Поэтому в распечатке видно, что было 
прочитано 12 байт, хотя пакет 895 содержит только два целых. При следующем 
чтении возвращено два целых из пакета 896, и telemetrys напечатал мусор вмсс- 
то числа значений, так как telemetryc He инициализировал второе значение. 


Готово 8 байт t Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 
Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 


ру 


Прочитано 12 байт 


Готово 28 байт 
Прочитано 12 байт 


у Прочитано 4 байта 


Рис. 2.21. фатальная ошибка 


Как видно из рис. 2.21, то же самое произошло с пакетами 897 и 898, так что 
при следующем чтении было доступно уже 28 байт. Теперь telemetrys читает 
пакет 899 и первое значение из пакета 900, остаток пакета 900 и первое значение 
из пакета 901 и наконец последнее значение из пакета 901. Последняя операция 
чтения возвращает только 4 байта, поэтому проверка в строке 19 завершается не- 
удачно, а моделирование – с ошибкой. 

К сожалению, на более раннем этапе моделирования произошло еще худшее. 


Пакет 31 содержит 2 значения в 8 байтах 

Пакет 32 содержит 3 значения в 12 байтах 

Пакет 33 содержит 2 значения в 12 байтах 

Пакет 34 содержит -268436204 значения в 8 байтах 
Пакет 35 содержит 2 значения в 8 байтах 

Пакет 36 содержит 3 значения в 12 байтах 
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Всего через 33 с после начала моделирования произошла ошибка, оставшаяся 
необнаруженной. Как показано на рис. 2.22, когда telemetrys читал пакет 33, 
в буфере было 20 байт, поэтому операция чтения вернула 12 байт вместо 8. Это 
означает, что пакет с двумя значениями ошибочно был принят за пакет с тремя зна- 
чениями, а затем наоборот. Начиная с пакета 35, telemetrys восстановил синхро- 
низацию, и ошибка прошла незамеченной. 


Готово 8 байт ) Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 


Готово 8 байт Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


"ОН, ЧН ИЕР НИНУ ERE 


Рис. 2.22. Незамеченная ошибка 


Резюме 


Локальная сеть, которая представляет собой почти идеальную среду, может мас- 
кировать проблемы производительности и даже ошибки. Не думайте, что приложе- 
ние, работающее в локальной сети, будет также хорошо работать и в глобальной. 

Из-за сетевых задержек приложение, производительность которого в локаль- 
ной сети была удовлетворительной, в глобальной сети может работать неприем- 
лемо медленно. В результате иногда приходится перепроектировать программу. 

Из-за перегрузок в интенсивно используемой глобальной сети, особенно B Ín- 
ternet, данные могут доставляться как внезапно, так и пакетами неожиданного раз- 
мера. Это требует от вас особой осторожности в допущениях о том, сколько дан- 
ных может прийти в определенный момент и с какой частотой они поступают. 

Хотя в этом разделе говорилось исключительно о протоколе ТСР, то же отно- 
сится и к UDP, поскольку он не обладает встроенной надежностью, чтобы проти- 
востоять тяжелым условиям B Internet. 


Совет 13. Изучайте работу протоколов 


В книге [Stevens 1998] автор отмечает, что основные проблемы в сетевом про- 
граммировании не имеют отношения ни к программированию, ни к API. Они воз- 
никают из-за непонимания работы сетевых протоколов. Это подтверждают вопро- 
сы, которые задают в конференциях, посвященных сетям (совет 44). Например, 
некто, читая справочную документацию на своей UNIX- или Windows-Mwarnne, 
обнаруживает, как отключить алгоритм Нейгла. Но если он не понимает принципов 
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управления потоком, заложенных в ТСР и роли этого алгоритма, то вряд ли раз- 
берется, когда имеет смысл его отключать, а когда — нет, 

Точно так же, отсутствие механизма немедленного уведомления о потере CBA- 
зи, обсуждавшееся в совете 10, может показаться серьезным недостатком, если вы 
не понимаете, почему было принято такое решение. Разобравшись с причинами, 
можно без труда организовать обмен сообщениями-пульсами именно с той часто- 
той, которая нужна конкретному приложению. 

Есть несколько способов изучить протоколы, и многие из них будут рассмотрены 
в главе 4. Основной источник информации о протоколах TCP/IP - это ВЕС, кото- 
рый официально определяет, как они должны работать. В RFC обсуждается ши- 
рокий спектр вопросов разной степени важности, в том числе все протоколы из се- 
мейства TCP/IP. Все RFC, а также сводный указатель находятся на следующем сайте: 
http://www.rfc-editororg. 

В совете 43 описаны также другие способы получения RFC. 

Поскольку ВЕС - это плод труда многих авторов, они сильно различаются 
доступностью изложения. Кроме того, некоторые вопросы освещаются в несколь- 
ких ВЕС и не всегда просто составить целостную картину. 

Существуют и другие источники информации о протоколах, более понятные для 
начинающих. Два из них будут рассмотрены здесь, а остальные - в главе 4. 

В книге [Comer 1995] описываются основные протоколы TCP/IP и то, как они 
должны работать, с точки зрения ВЕС. Здесь содержатся многочисленные ссылки 
на ВЕС, которые облегчают дальнейшее изучение предмета и дают общее представ- 
ление об организации ВЕС. Поэтому некоторые считают эту книгу теоретическим 
введением B противоположность книгам [Stevens 1994; Stevens 1995], где представ- 
лен подход, ориентированный в основном на практическое применение. 

В книгах Стивенса семейство протоколов TCP/IP исследуется с точки зрения 
реализации. Иными словами, показывается, как основные реализации TCP/IP pa- 
ботают в действительности. В качестве инструмента исследования используются, 
главным образом, данные, выдаваемые программой tcpdump (совет 34), и времен- 
ные диаграммы типа изображенной на рис. 2.16. В сочетании с детальным изложе- 
нием форматов пакетов и небольшими тестовыми программами, призванными про- 
яснить некоторые аспекты работы обсуждаемых протоколов, это дает возможность 
ясно представить себе их функционирование. С помощью формального описания 
добиться этого было бы трудно. 

Хотя в этих книгах приняты разные подходы к освещению протоколов ТСР/ 
ТР, не следует думать, будто один подход чем-то лучше другого, а стало быть, от- 
давать предпочтение только одной книге. Полезность каждой книги зависит от 
поставленной перед вами задачи в данный момент. По сути, издания взаимно до- 
полняют друг друга. И серьезный программист, занимающийся разработкой сете- 
вых приложений, должен включить эти две книги в свою библиотеку. 


Резюме 


В этом разделе обсуждалось, насколько важно разбираться в функционирова- 
нии протоколов. Отмечено, что официальной спецификацией TCP/IP являются 
ВЕС и рекомендованы книги Комера и Стивенса в качестве дополнительного ис- 
точника информации о протоколах и их работе. 
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Совет 14. Не воспринимайте слишком серьезно 
семиуровневую эталонную модель OSI 


Поскольку задача проектирования и реализации сетевых протоколов очень слож- 
на, обычно ее разделяют на меньшие части, более простые для понимания. Традици- 
онно для этого используется концепция уровней. Каждый уровень предоставляет 
сервисы уровням выше себя и пользуется сервисами нижележащих уровней. 

Например, на рис. 2.1, где изображен упрощенный стек протоколов TCP/IP, ypo- 
вень IP предоставляет сервис, именуемый доставкой датаграмм, уровням ТСР и UDP. 
Чтобы обеспечить такой сервис, [Р пользуется сервисами для передачи датаграмм фи- 
зическому носителю, которые предоставляет уровень сетевого интерфейса. 


Модель OSI 


Наверное, самый известный пример многоуровневой схемы сетевых протоко- 
лов — это эталонная модель открытого взаимодействия систем (Reference Model 
of Open Systems Interconnection), предложенная Международной организацией по 
стандартизации (ISO). 


Примечание Многие ошибочно полагают, что в модели OSI были впервые вве- 
дены концепции разбиения на уровни, виртуализации и многие 
другие. На самом деле, эти идеи были хорошо известны и актив- 
но применялись разработчиками сети ARPANET, которые co- 
здали семейство протоколов TCP/IP задолго до появления моде- 
ли OSI. Об истории этого вопроса вы можете узнать в RFC 871 
[Padlipsky 1982]. 


Поскольку B этой модели семь уровней (рис. 2.23), 
ее часто называют семиуровневой моделью OSI. 

Как уже отмечалось, уровень М предоставляет сер- 
висы уровню N+1 и пользуется сервисами, предостав- 
ляемыми уровнем N-1. Кроме того, каждый уровень 
может взаимодействовать только со своими непосред- 
ственными соседями сверху и снизу. Это взаимо- 
действие происходит посредством четко определенных 
интерфейсов между соседними уровнями, поэтому 
в принципе реализацию любого уровня можно заме- 
нить при условии, что новая реализация предостав- 
ляет в точности те же сервисы, и это не отразится 
на остальных уровнях. Одноименные уровни в комму- 
никационных стеках обмениваются данными (по сети) с помощью протоколов. 

Эти уровни часто упоминаются в литературе по вычислительным сетям. Каж- 
дый из них предоставляет следующие сервисы: 


Прикладной уровень 
Уровень представления 
Сеансовый уровень 
Транспортный уровень 


Сетевой уровень 


Q aA O O N 


Канальный уровень 


Физический уровень 


Рис. 2.23. Семиуровневая 
талонная модель OSI 


о физический уровень. Этот уровень связан с аппаратурой. Здесь определяются 
электрические и временные характеристики интерфейса, способ передачи би- 
тов физическому носителю, кадрирование и даже размеры и форма разъемов; 
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О канальный уровень. Это программный интерфейс к физическому уровню. 
В его задачу входит предоставление надежной связи с последним. На этом 
уровне находятся драйверы устройств, используемые сетевым уровнем для 
общения с физическими устройствами. Кроме того, этот уровень обеспечи- 
вает формирование кадров для канала, проверку контрольных сумм с целью 
обнаружения искажения данных и управление совместным доступом к фи- 
зическому носителю. Обычно задача интерфейса между сетевым и каналь- 
ным уровнями — создание механизма, обеспечивающего независимость OT 
конкретного устройства; 

О сетевой уровень. Этот уровень занимается доставкой пакетов от одного узла 
другому. Он отвечает за адресацию и маршрутизацию, фрагментацию и сбор- 
ку, а также за управление потоком и предотвращение перегрузок; 

о транспортный уровень. Реализует надежную сквозную связь между узлами 
сети, а также управление потоком и предотвращение перегрузок. Он компен- 
сирует ненадежность, присущую нижним уровням, за счет обработки оши- 
бок, которые вызваны искажением данных, потерей пакетов и их доставкой 
не по порядку; 

О сеансовый уровень. Транспортный уровень предоставляет надежный полно- 
дуплексный коммуникационный канал между двумя узлами. Сеансовый 
уровень добавляет такие сервисы, как организация и уничтожение сеанса 
(например, вход в систему и выход из нее), управление диалогом (эмуляция 
полудуплексного терминала), синхронизация (создание контрольных точек 
при передаче больших файлов) и иные надстройки над надежным протоко- 
лом четвертого уровня; 

о уровень представления. Отвечает за представление данных, например, npe- 
образование форматов (скажем, из кода ASCII в код EBCDIC) и сжатие; 

О прикладной уровень. На нем располагаются пользовательские программы, 
использующиеся остальными четырьмя уровнями для обмена данными. Из- 
вестные из мира TCP/IP примеры ~ это telnet, ftp, почтовые клиенты и Web- 
браузеры. 


Официальное описание семиуровневой модели OSI приведено в документе 
[International Standards Organization 1984], но оно лишь в общих чертах деклариру- 
ет, что должен делать каждый уровень. Детальное описание сервисов, предоставля- 
емых протоколами на отдельных уровнях, содержится в других документах ISO. 
Довольно подробное объяснение модели и ее различных уровней со ссылками на 
соответствующие документы ISO можно найти в работе [Jain and Agrawala 1993]. 

Хотя модель OSI полезна как основа для обсуждения сетевых архитектур 
и реализаций, ее нельзя рассматривать как готовый чертеж для создания любой 
сетевой архитектуры. Не следует также думать, что размещение некоторой функ- 
ции на уровне М в этой модели означает, что только здесь наилучшее для нее место. 

Модель OSI имеет множество недостатков. Хотя, в конечном итоге, были со- 
зданы работающие реализации, протоколы ОЗ] на сегодняшний день утратили ак- 
туальность. Основные проблемы этой модели в том, что, во-первых, распределение 
функций между уровнями произвольно и не всегда очевидно, во-вторых, она была 
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спроектирована (комитетом) без готовой реализации. Вспомните, как разрабаты- 
вался TCP/IP, стандарты которого основаны на результатах экспериментов. 

Другая проблема модели OSI ~ это сложность и неэффективность. Некоторые 
функции выполняются сразу на нескольких уровнях. Так, обнаружение и исправ- 
ление ошибок происходит на большинстве уровней. 

Как отмечено в книге [Tanenbaum 1996], один из основных дефектов модели 
OSI состоит в том, что она страдает «коммуникационной ментальностью». Это 
относится и к терминологии, отличающейся от общеупотребительной, и к специ- 
фикации примитивов интерфейсов между уровнями, которые более пригодны для 
телефонных, а не вычислительных сетей. 

Наконец, выбор именно семи уровней продиктован, скорее, политическими, 
а не техническими причинами. В действительности сеансовый уровень и уровень 
представления редко встречаются в реально работающих сетях. 


Модель TCP/IP 


Сравним модель OSI с моделью TCP/IP. Важно отдавать себе отчет в том, что 
модель TCP/IP документирует дизайн семейства протоколов TCP/IP. Ee не пред- 
полагалось представлять в качестве эталона, как модель OSI. Поэтому никто и не 
рассматривает ее как основу для проектирования новых сетевых архитектур. Тем 
не менее поучительно сравнить две модели и посмотреть, как уровни TCP/IP ото- 
бражаются на уровни модели OSI. По крайней мере, это напоминает, что модель- 
OSI - не единственный правильный путь. 


Прикладной уровень 
Уровень представления Прикладной уровень telnet, ftp, ит.д. 
Сеансовый уровень 
Транспортный уровень Транспортный уровень | ТСР, UDP 
Сетевой уровень Межсетевой уровень IP, ICMP, IGMP 


Канальный уровень 
Интерфейсный уровень 


Физический уровень 


Модель OSI Стек ТСРЛР 


Рис. 2.24. Сравнение модели OSI и стека TCP/IP 


Как видно из рис. 2.24, стек протоколов TCP/IP состоит из четырех уровней. 
На прикладном уровне решаются все задачи, свойственные прикладному уровню, 
уровню представления и сеансовому уровню модели OSI. Транспортный уровень 
аналогичен соответствующему уровню в OSI и занимается сквозной доставкой. 
На транспортном уровне определены протоколы ТСР и UDP, Ha межсетевом - 
протоколы IP, ICMP и IGMP (Internet Group Management Protocol). Он соответ- 
ствует сетевому уровню модели OSI. 
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Примечанае С протоколом IP вы уже знакомы. [СМР (Internet Control Message 
Protocol) — это межсетевой протокол контрольных сообщений, 
который используется для передачи управляющих сообщений 
и информации об ошибках между системами. Например, сооб- 
щение «хост недоступен» передается по протоколу ICMP, рав- 
но как запросы и ответы, формируемые утилитой ping. [СМР 
(Internet Group Management Protocol) — это межсетевой npomo- 
кол управления группами, с помощью которого хосты сообща- 
ют маршрутизаторам, поддерживающим групповое вещание, 
о принадлежности к локальным группам. Хотя сообщения 
протоколов [СМР и [СМР передаются в виде ІР-датаграмм, они 
рассматриваются как неотземлемая часть IP, а не как прото- 
колы более высокого уровня. 


Интерфейсный уровень отвечает за взаимодействие между компьютером и фи- 
зическим сетевым оборудованием. Он приблизительно соответствует канальному 
и физическому уровням модели OSI. Интерфейсный уровень по-настоящему не 
описан в документации по архитектуре TCP/IP. Там сказано только, что он обес- 
печивает доступ к сетевой аппаратуре системно-зависимым способом. 

Прежде чем закончить тему уровней в стеке TCP/IP, рассмотрим, как проис- 
ходит общение между уровнями стека протоколов в компьютерах на разных кон- 
цах сквозного соединения. Ha рис. 2.25 изображены два стека TCP/IP на компью- 
терах, между которыми расположено несколько маршрутизаторов. 

Вы знаете, что приложение передает данные стеку протоколов. Потом они 
опускаются вниз по стеку, передаются по сети, затем поднимаются вверх по стеку 
протоколов компьютера на другом конце и наконец попадают в приложение. Но 
при этом каждый уровень стека работает так, будто на другом конце находится 
только этот уровень и ничего больше. Например, если в качестве приложения вы- 
ступает ЕТР то ЕТР-клиент «говорит» непосредственно с ЕТР-сервером, не имея 
сведений о том, что между ними есть ТСР, [Р и физическая сеть. 

Это верно и для других уровней. Например, если на транспортном уровне ис- 
пользуется протокол ТСР, то он общается только с протоколом ТСР на другом 
конце, не зная, какие еще протоколы и сети используются для поддержания «бесе- 
ды». В идеале должно быть так: если уровень М посылает сообщение, то уровень N 
на другом конце принимает только его, а все манипуляции, произведенные над 
этим сообщением нижележащими уровнями, оказываются невидимыми. 

Последнее замечание требует объяснения. На рис. 2.25 вы увидите, что транс- 
портный уровень — самый нижний из сквозных уровней, то есть таких, связь меж- 
ду которыми устанавливается без посредников. Напротив, в «разговоре» на межсе- 
тевом уровне участвуют маршрутизаторы или полнофункциональные компьютеры, 
расположенные на маршруте сообщения. 


Примечание Предполагается наличие промежуточных маршрутизаторов, 
то есть сообщение не попадает сразу в конечный пункт. 
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Прикладной протокол 


Межсетевой 


уровень 
Интерфейсный - 20 - Интерфейсный 


EDD 


Рис. 2.25. Сквозная связь 


Но промежуточные системы могут изменять некоторые поля, например, вре- 
мя существования датаграммы (TTL - time to live) в [Р-заголовке. Поэтому меж- 
сетевой уровень в пункте назначения может «видеть» не в точности то же сообще- 
ние, что межсетевой уровень, который его послал. 

Этот подчеркивает различие между межсетевым и транспортным уровнями, 
Межсетевой уровень отвечает за доставку сообщений в следующий узел на марш- 
руте. И он общается с межсетевым уровнем именно этого узла, а не C межсетевым 
уровнем в конечной точке. Транспортные же уровни контактируют напрямую, не 
имея информации о существовании промежуточных систем. 


Резюме 


В этом разделе дано сравнение моделей OSI и TCP/IP. Вы узнали, что семи- 
уровневая модель OSI нужна как средство описания сетевой архитектуры, HO CO- 
зданные на ее базе реализации почти не имеют успеха. 


E E И О О ООО ОО ООО 


Глава 3. Создание эффективных 
и устойчивых сетевых программ 


Совет 15. Разберитесь с операцией записи в ТСР 


Здесь и далее обсуждаются некоторые особенности операций чтения и записи 
при программировании TCP/IP. Представляет интерес не конкретный API и дета- 
ли системных вызовов, а семантические вопросы, связанные с этими операциями. 

Как сказано в совете 6, между операциями записи и посылаемыми ТСР сег- 
ментами нет взаимно-однозначного соответствия. Как именно соотносятся обра- 
щения к операции записи с протоколом ТСР, зависит от системы, но все же специ- 
фикации протокола достаточно определенны и можно сделать некоторые выводы 
при знакомстве с конкретной реализацией. Традиционная реализация подробно 
описана в системе BSD. Она часто рассматривается как эталонная, и ее исходные 
тексты доступны. 


Примечание Исходные тексты оригинальной реализации для системы 
4.4BSD-lite2 можно получить на CD-ROM у компании Walnut 
Creek (http;// www.cdrom.com). Подробные пояснения к исход- 
ному тексту вы найдете в книге [Wright and Stevens 1995]. 


Операция записи с точки зрения приложения 


Когда пользователь выполняет запись в ТСР-соединение, данные сначала ко- 
пируются из буфера пользователя в память ядра. Дальнейшее зависит от состоя- 
ния соединения. ТСР может «решить», что надо послать все данные, только часть 
или ничего не посылать. О том, как принимается решение, будет сказано ниже. 
Сначала рассмотрим операцию записи с точки зрения приложения. 

Хочется думать, что если операция записи п байт вернула значение п, то все 
эти п байт, действительно, переданы на другой конец и, возможно, уже подтверж- 
дены. Увы, это не так. ТСР посылает столько данных, сколько возможно (или ни- 
чего), и немедленно возвращает значение п. Приложение не определяет, какая 
часть данных послана и были ли они подтверждены. 

В общем случае операция записи не блокирует процесс, если только буфер пе- 
редачи ТСР не полон. Это означает, что после записи управление почти всегда 
быстро возвращается программе. После получения управления нельзя ничего га- 
рантировать относительно местонахождения «записанных» данных. Как упомина- 
лось в совете 9, это имеет значение для надежности передачи данных. 


СЕРИИ ШИЕ: создание эффективных сетевых программ 


С точки зрения приложения данные записаны. Поэтому, помня о гарантиях 
доставки, предлагаемых TCP, можно считать, что информация дошла до другого 
конца. В действительности, некоторые (или все) эти данные в момент возврата из 
операции записи могут все еще стоять в очереди на передачу. И если хост или при 
ложение на другом конце постигнет крах, то информация будет потеряна. 


Примечание Если отправляющее приложение завершает сеанс аварийно, то 
ТСР все равно будет пытаться доставить данные. 


Еще один важный момент, который нужно иметь в виду, — это обработка ошиб- 
ки записи. Если при записи на диск вызов write не вернул код ошибки, то точно 
известно, что запись была успешной. 


Дреиечание Строго говоря, это неверно. Обычно данные находятся в буфере 
в пространстве ядра до того момента, пока не произойдет сброс 
буферов на диск. Поэтому если до этого момента система «yna- 
дет», то данные вполне могут быть потеряны. Но суть в том 
что после возврата из write уже не будет никаких сообщений об 
ошибках. Можно признать потерю не сброшенных на диск дан- 
ных неизбежной, но не более вероятной, чем отказ самого диска. 


При работе с ТСР получение кода ошибки от операции записи — очень редкое 
явление. Поскольку операция записи возвращает управление до фактической от- 
правки данных, обычно ошибки выявляются при последующих операциях, о чем 
говорилось в совете 9. Так как следующей операцией чаще всего бывает чтение 
предполагается, что ошибки записи обнаруживаются при чтении. Операция запи- 
си возвращает лишь ошибки, очевидные в момент вызова, а именно: 


о неверный дескриптор сокета; 

о файловый дескриптор указывает He на сокет (в случае вызова send и род- 
ственных функций); 

о указанный при вызове сокет не существует или не подсоединен; 

О вкачестве адреса буфера указан недопустимый адрес. 


Причина большинства этих проблем — ошибка в программе. После заверше- 
ния стадии разработки они почти не встречаются. Исключение составляет код 
ошибки EPIPE (или сигнал SIGPIPE), который свидетельствует о сбросе соедине- 
ния хостом на другом конце. Условия, при которых такая ошибка возникает, об- 
суждались в совете 9 при рассмотрении краха приложения-партнера. 

Подводя итог этим рассуждениям, можно сказать, что применительно к ТСР- 
соединениям операцию записи лучше представлять себе как копирование в оче- 
редь для передачи, сопровождаемое извещением ТСР о появлении новых данных. 
Понятно, какую работу ТСР произведет дальше, но эти действия будут асинхрон- 
ны по отношению к самой записи. 


Операция записи с точки зрения ТСР 


Как отмечалось выше, операция записи отвечает лишь за копирование данных 
из буфера приложения в память ядра и уведомление ТСР о том, что появились 
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новые данные для передачи. А теперь рассмотрим некоторые из критериев, кото- 
рыми руководствуется ТСР «принимая решение» о TOM, можно ли передать новые 
данные незамедлительно и в каком количестве. Я не задаюсь целью полностью 
объяснить логику отправки данных в ТСР ахочу лишь помочь вам составить пред- 
ставление о факторах, влияющих на эту логику. Тогда вы сможете лучше понять 
принципы работы своих программ. 

Одна из основных Целей стратегии отправки данных в ТСР — максимально эф- 
фективное использование имеющейся полосы пропускания. ТСР посылает данные 
блоками, размер которых равен MSS (maximum segment size — максимальный раз- 
мер сегмента). 


Примечание В процессе установления соединения ТСР на каждом конце мо- 
жет указать приемлемый для него MSS. ТСР на другом конце 
обязан удовлетворить это пожелание и не посылать сегменты 
большего размера. MSS вычисляется на основе MTU (maximum 
transmission unit — максимальный размер передаваемого блока), 
как описано в совете 7. 


Вто же время ТСР не может переполнять буферы на принимающем конце. Как 
вы видели в совете 1, это определяется окном передачи. 

Если бы эти два условия были единственными, то стратегия отправки была бы 
проста: немедленно послать все имеющиеся данные, упаковав их в сегменты раз- 
MepoM MSS, но не более чем разрешено окном передачи. К сожалению, есть и дру- 
гие факторы. 

Прежде всего, очень важно не допускать перегрузки сети. Если ТСР неожи- 
данно пошлет в сеть большое число сегментов, может исчерпаться память марш- 
рутизатора, что повлечет за собой отбрасывание датаграмм. А из-за этого начнутся 
повторные передачи, что еще больше загрузит сеть. В худшем случае сеть будет 
загружена настолько, что датаграммы вообще нельзя будет доставить. Это называ- 
ется затором (congestion collapse). Чтобы избежать перегрузки, TCP не посылает 
по простаивающему соединению все сегменты сразу. Сначала он посылает один 
сегмент и постепенно увеличивает число неподтвержденных сегментов в сети, пока 
не будет достигнуто равновесие. 


Примечание Эту проблему можно наглядно проиллюстрировать таким при- 
мером. Предположим, что в комнате, полной народу, кто-то 
закричал: «Пожар!» Все одновременно бросаются к дверям, воз- 
никает давка, и в результате никто не может выйти. Если же 
люди будут выходить по одному, то пробки не возникнет, и все 
благополучно покинут помещение. 


Для предотврашения перегрузки ТСР применяет два алгоритма, в которых исполь- 
зуется еще одно окно, называемое окном перегрузки. Максимальное число байтов, 
которое ТСР может послать в любой момент, — это минимальная из двух величин: 
размер окна передачи и размер окна перегрузки. Обратите внимание, что эти окна 
отвечают за разные аспекты управления потоком. Окно передачи, декларируемое 
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ТСР на другом конце, предохраняет от переполнения его буферов. Окно перегруз- 
ки, отслеживаемое ТСР на вашем конце, не дает превысить пропускную способ- 
ность сети. Ограничив объем передачи минимальным из этих двух окон, вы удов- 
летворяете обоим требованиям управления потоком. 

Первый алгоритм управления перегрузкой называется «медленный старт». Он 
постепенно увеличивает частоту передачи сегментов в сеть до пороговой величины. 


Примечание Слово «медленный» взято в кавычки, поскольку на самом деле 
нарастание частоты экспоненциально. При медленном старте 
окно перегрузки открывается на один сегмент при получении 
каждого АСК. Если вы начали с одного сегмента, то последова- 
тельные размеры окна будут составлять 1, 2, 4, 8 ит.д. 


Когда размер окна перегрузки достигает порога, который называется порогом 
медленного старта, этот алгоритм прекращает работу, и в дело вступает алгоритм 
избежания перегрузки. Его работа предполагает, что соединение достигло равно- 
весного состояния, и сеть постоянно зондируется - не увеличилась ли пропускная 
способность. На этой стадии окно перегрузки открывается линейно — по одному 
сегменту за период кругового обращения. 

В стратегии отправки ТСР окно перегрузки в принципе может запретить посы- 
лать данные, которые в его отсутствие можно было бы послать. Если происходит 
перегрузка (о чем свидетельствует потерянный сегмент) или сеть некоторое время 
простаивает, то окно перегрузки сужается, возможно, даже до размера одного сег- 
мента. В зависимости от того, сколько данных находится в очереди, и сколько их 
пытается послать приложение, это может препятствовать отправке всех данных. 

Авторитетным источником информации об алгоритмах избежания перегрузки 
является работа [Jacobson 1988], в которой они впервые были предложены. Дже- 
кобсон привел результаты нескольких экспериментов, демонстрирующие замет- 
ное повышение производительности сети после внедрения управления перегруз- 
кой. В книге [Stevens 1994] содержится подробное объяснение этих алгоритмов 
и результаты трассировки в локальной сети. В настоящее время эти алгоритмы сле- 


дует включать в любую реализацию, согласующуюся со стандартом (RFC 1122 
[Braden 1989]). 


Примечание Несмотря на впечатляющие результаты, реализация этих ал- 
горитмов очень проста - всего две переменные состояния и не- 
сколько строчек кода. Детали можно найти в книге [Wright and 
Stevens 1995]. 


Еще один фактор, влияющий на стратегию отправки ТСР, – алгоритм Нейгла. 
Этот алгоритм впервые предложен в ВЕС 896 [Маше 1984]. Он требует, чтобы HH- 
когда не было более одного неподтвержденного маленького сегмента, то есть сег- 
мента размером менее MSS. Цель алгоритма Нейгла — не дать ТСР забить сеть пос- 
ледовательностью мелких сегментов. Вместо этого ТСР сохраняет в своих буферах 
небольшие блоки данных, пока не получит подтверждение на предыдущий малень- 
кий сегмент, после чего посылает сразу все накопившиеся данные. В совете 24 вы 
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увидите, что отключение алгоритма Нейгла может заметно сказаться на произво- 
дительности приложения. 

Если приложение записывает данные небольшими порциями, то эффект от ал- 
горитма Нейгла очевиден. Предположим, что есть простаивающее соединение, окна 
передачи и перегрузки достаточно велики, а выполняются подряд две небольшие 
операции записи. Данные, записанные вначале, передаются немедленно, поскольку 
окна это позволяют, а алгоритм Нейгла не препятствует, так как неподтвержденных 
данных нет (соединение простаивало). Но, когда до ТСР доходят данные, получен- 
ные при второй операции, они не передаются, хотя в окнах передачи и перегрузки 
есть место. Поскольку уже есть один неподтвержденный маленький сегмент, и алго- 
ритм Нейгла требует оставить данные в очереди, пока не придет АСК. 

Обычно при реализации алгоритма Нейгла не посылают маленький сегмент, 
если есть неподтвержденные данные. Такая процедура рекомендована RFC 1122. 
Но реализация в BSD (и некоторые другие) несколько отходит от этого правила 
и отправляет маленький сегмент, если это последний фрагмент большой одновре- 
менно записанной части данных, а соединение простаивает. Например, MSS для 
простаивающего соединения равен 1460 байт, а приложение записывает 1600 байт. 
При этом ТСР пошлет (при условии, что это разрешено окнами передачи и пере- 
грузки) сначала сегмент размером 1460, а сразу вслед за ним, не дожидаясь под- 
тверждения, сегмент размером 140. При строгой интерпретации алгоритма Ней- 
гла следовало бы отложить отправку второго сегмента либо до подтверждения 
первого, либо до того, как приложение запишет достаточно данных для формиро- 
вания полного сегмента. 

Алгоритм Нейгла — это лишь один из двух алгоритмов, позволяющих избе- 
жать синдрома безумного окна (SWS — silly window syndrome). Смысл этой так- 
тики в том, чтобы не допустить отправки небольших объемов данных. Синдром 
SWS и его отрицательное влияние на производительность обсуждаются в ВЕС 813 
[Clark 1982]. Как вы видели, алгоритм Нейгла пытается избежать синдрома SWS 
со стороны отправителя. Но требуются и усилия со стороны получателя, который 
не должен декларировать слишком маленькие окна. 

Напомним, что окно передачи дает оценку свободного места в буферах хоста 
на другом конце соединения. Этот хост объявляет о том, сколько в нем имеется 
места, включая в каждый посылаемый сегмент информацию об обновлении окна. 
Чтобы избежать SWS, получатель не должен объявлять о небольших изменениях. 

Следует пояснить это на примере. Предположим, у получателя есть 14600 сво- 
бодных байт, а М$$ составляет 1460 байт. Допустим также, что приложением на 
конце получателя читается за один раз всего по 100 байт. Отправив получателю 
10 сегментов, окно передачи закроется. И вы будете вынуждены приостановить от- 
правку данных. Но вот приложение прочитало 100 байт, в буфере приема 100 байт 
освободилось. Если бы получатель объявил об этих 100 байтах, то вы тут же послали 
бы ему маленький сегмент, поскольку ТСР временно отменяет алгоритм Нейгла, 
если из-за него длительное время невозможно отправить маленький сегмент. Вы 
и дальше продолжали бы посылать стобайтные пакеты, так как всякий раз, когда 
приложение на конце получателя читает очередные 100 байт, получатель объявляет 
об освобождении этих 100 байт, посылая информацию об обновлении окна. 
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Алгоритм избежания синдрома SWS на получающем конце не позволяет 
объявлять об обновлении окна, если объем буферной памяти значительно не уве- 
личился. В ВЕС 1122 «значительно» — это на размер полного сегмента или более 
чем на половину максимального размера окна. В реализациях, производных от 
BSD, требуется увеличение на два полных сегмента или на половину максималь- 
ного размера окна. 

Может показаться, что избежание SWS со стороны получателя излишне (по- 
скольку отправителю не разрешено посылать маленькие сегменты), но в действи- 
тельности это защита от тех стеков TCP/IP в которых алгоритм Нейгла не реали- 
зован или отключен приложением (совет 24). ВЕС 1122 требует от реализаций 
ТСР удовлетворяющих стандарту, осуществлять избежание SWS на обоих концах. 

На основе этой информации теперь можно сформулировать стратегию отправ- 
ки, принятую в реализациях ТСР, производных от BSD. В других реализациях 
стратегия может быть несколько иной, но основные принципы сохраняются. 

При каждом вызове процедуры вывода ТСР вычисляет объем данных, кото- 
рые можно послать. Это минимальное значение количества данных в буфере пере- 
дачи, размера окон передачи и перегрузки и MSS. Данные отправляются при вы- 
полнении хотя бы одного из следующих условий: 


О можно послать полный сегмент размером MSS; 

О соединение простаивает, и можно опустошить буфер передачи; 

О алгоритм Нейгла отключен, и можно опустошить буфер передачи; 

О есть срочные данные для отправки; 

О есть маленький сегмент, HO его отправка уже задержана на достаточно дли- 
тельное время; 


Примечание Если у ТСР есть маленький сегмент, который запрещено посы- 
лать, то он взводит таймер на то время, которое потребова- 
лось бы для ожидания АСК перед повторной передачей (но в пре- 
делах 5-60 с). Иными словами, устанавливается тайм-аут 
ретрансмиссии (КТО). Если этот таймер, называемый тайме- 
ром терпения (persist timer), срабатывает, то ТСР все-таки no- 
сылает сегмент при условии, что это не противоречит ограниче- 
ниям, которые накладывают окна передачи и перегрузки. Даже 
если получатель объявляет окно размером нуль байт, ТСР все рав- 
но попытается послать один байт. Это делается для того, umo» 
бы потерянное обновление окна не привело к тупиковой ситуации. 
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О окно приема, объявленное XOCTOM на другом конце, открыто не менее чем Ha- 
половину; 

о необходимо повторно передать сегмент; 

О требуется послать АСК на принятые данные; 

О нужно объявить об обновлении окна. 


Резюме 


Вэтом разделе подробно рассмотрена операция записи. С точки зрения прило- 
жения операцию записи проще всего представлять как копирование из адресного 


Аккуратное размыкание ТСР-соединений ТТТ | |137 


пространства пользователя в буферы ядра и последующий возврат. Срок переда- 
чи данных ТСР и их объем зависят от состояния соединения, а приложение не 
имеет подобной информации. 

Проанализированы стратегия отправки, принятая в BSD ТСР а также влия- 
ние на нее объема буферной памяти у получателя (представлен окном Передачи), 
оценки загрузки сети (представлена окном перегрузки), объема данных, готовых 
для передачи, попытки избежать синдрома безумного окна и стратегии повторной 
передачи. 


Совет 16. Разберитесь с аккуратным размыканием 
ТСР-соединений 
Как вы уже видели, в работе ТСР-соединения есть три фазы: 


1. Установления соединения. 
2. Передачи данных. 
3. Разрыва соединения. 


Вэтом разделе будет рассмотрен переход от фазы передачи данных к фазе раз- 
рыва соединения. Точнее, как узнать, что хост на другом конце завершил фазу пе- 
редачи данных и готов к разрыву соединения, и как он может сообщить об этом 
партнеру. 

Вы увидите, что один хост может прекратить отправку данных и сигнализиро- 
вать партнеру об этом, не отказываясь, однако, от приема данных. Это возможно, 
поскольку ТСР-соединения полнодуплексные, потоки данных в разных направле- 
ниях не зависят друг от друга. 

Например, клиент может соединиться с сервером, отправить серию запросов, 
а затем закрыть свою половину соединения, предоставив тем самым серверу ин- 
формацию, что больше запросов не будет. Серверу для ответа клиенту, возможно, 
понадобится выполнить большой объем работы и даже связаться с другими серве- 
рами, так что он продолжает посылать данные уже после того, как клиент прекра- 
тил отправлять запросы. С другой стороны, сервер может послать в ответ сколько 
угодно данных, так что клиент не определяет заранее, когда ответ закончится. По- 
этому сервер, вероятно, как и клиент, закроет свой конец соединения, сигнализи- 
руя о конце передачи. 

После того как ответ на последний запрос клиента отправлен и сервер закрыл 
свой конец соединения, ТСР завершает фазу разрыва. Обратите внимание, что за- 
крытие соединения рассматривается как естественный способ известить партне- 
рао прекращении передачи данных. По сути, посылается признак конца файла ЕОЕ 


Вызов shutdown 


Как приложение закрывает свой конец соединения? Оно не может просто за- 
вершить сеанс или закрыть сокет, поскольку у партнера могут быть еще данные. 
В API сокетов есть интерфейс shutdown. Он используется так же, как и вызов 
close, но при этом передается дополнительный параметр, означающий, какую сто- 
рону соединения надо закрыть. 
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d$include «sys/socket.h» /* UNIX. */ 
d$include «winsock2.h» /* Windows. */ 


int shutdown( int s, int how ); /* UNIX. */ 
int shutdown( SOCKET s, int how ); /* Windows. */ 


Возвращаемое значение: 0 — нормально, —1 (UNIX) или SOCKET. ERROR 
(Windows) — ошибка. 


К сожалению, между реализациями shutdown в UNIX и Windows есть разли- 
чия в семантике и API. Традиционно в качестве значений параметра how вызова 
shutdown использовались числа. И в стандарте POSIX, и в спецификации Winsock 
им присвоены символические имена, только разные. В табл. 3.1 приведены значе- 
ния, символические константы для них и семантика параметра how. 

Различия в символических именах можно легко компенсировать, определив 
в заголовочном файле одни константы через другие или используя числовые зна- 
чения. А вот семантические отличия гораздо серьезнее. Посмотрим, для чего пред- 
назначено каждое значение. 


Таблица 3.1. Значения параметра how для вызова shutdown 


Значение how 


Числовое POSIX Winsock действие 

0 SHUT RD SD RECEIVE Закрывается принимающая сторона соединения 
1 SHUT. WR SD SEND Закрывается передающая сторона соединения 
2 SHUT RDWR SD BOTH Закрываются обе стороны 


how = 0 Закрывается принимающая сторона соединения. В обеих реализациях 
в сокете делается пометка, что он больше не может принимать данные 
и должен вернуть EOF, если приложением делаются попытки еще что- 
то читать. Но отношение к данным, уже находившимся в очереди при- 
ложения в момент выполнения shut down, а также к приему новых дан- 
ных от хоста на другом конце различное. В UNIX все ранее принятые, 
но еще не прочитанные данные уничтожаются, так что приложение их 
уже не получит. Если поступают новые данные, то TCP их подтверж- 
дает и тут же отбрасывает, поскольку приложение не хочет принимать 
новые данные. Наоборот, в соответствии c Winsock соединение вообще 
разрывается, если в очереди есть еще данные или поступают новые. 
Поэтому некоторые авторы (например, [Quinn and Shute 1996]) счита- 
ют, что под Windows использование конструкции 


shutdown( s, 0 ); 


небезопасно. 

how = 1 Закрывается отправляющая сторона соединения. В сокете делается по- 
метка, что данные посылаться больше не будут; все последующие по- 
пытки выполнить для него операцию записи заканчиваются ошибкой. 
После того как вся информация из буфера отправлена, ТСР посылает 
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сегмент FIN, сообщая партнеру, что данных больше не будет. Это называ- 
ется полузакрытием (half close). Такое использование вызова shutdown 
наиболее типично, и его семантика в обеих реализациях одинакова. 

how = 2 Закрываются обе стороны соединения. Эффект такой же, как при вы- 
полнении вызова shutdown дважды, один раз c how = 0, а другой — 
с how = 1. Хотя, на первый взгляд, обращение 


shutdown( s, 2 ); 


эквивалентно вызову close или closesocket, B действительности это 
не так. Обычно нет причин для вызова shutdown с параметром how- 2, но 
в работе [Quinn and Shute 1996] сообщается, что в некоторых реализациях 
Winsock вызов с1озезосКеЕ работает неправильно, если предварительно 
не было обращения к shutdown c how = 2. В соответствии c Winsock вы- 
зов shutdown c how = 2 создает ту же проблему, что и вызов с how = 0, — 
может быть разорвано соединение. 


Между закрытием сокета и вызовом shutdown есть существенные различия. 
Во-первых, shutdown не закрывает сокет по-настоящему, даже если он вызван 
с параметром 2. Иными словами, ни сокет, ни ассоциированные с ним ресурсы (за 
исключением буфера приема, если how = 0 или 2) не освобождаются. Кроме того, 
воздействие shutdown распространяется на все процессы, в которых этот сокет OT- 
крыт. Так, например, вызов shutdown с параметром how = 1 делает невозможной 
запись в этот сокет для всех его владельцев. При вызове же close или closesocket 
все остальные процессы могут продолжать пользоваться сокетом. 

Последний факт во многих случаях можно обратить на пользу. Вызывая shutdown 
с how = 1, будьте уверены, что партнер получит EOF, даже если этот сокет открыт 
и другими процессами. При вызове close или closesocket это не гарантируется, 
поскольку ТСР не пошлет FIN, пока счетчик ссылок на сокет не станет равным 
нулю. А это произойдет только тогда, когда все процессы закроют этот сокет. 

Наконец, стоит упомянуть, что, хотя в этом разделе говорится о TCP, вызов 
shutdown применим ик ОРЮР Поскольку нет соединения, которое можно закрыть, 
польза обращения к shutdown с how = 1 или 2, остается под вопросом, но задавать 
параметр how = 0 можно для предотвращения приема датаграмм из конкретного 
ОБР-порта. 


Аккуратное размыкание соединений 


Теперь, когда вы познакомились с вызовом shutdown, посмотрите, как его MOX- 
но использовать для аккуратного размыкания соединения. Цель этой операции — 
гарантировать, что обе стороны получат все предназначенные им данные до того, 
как соединение будет разорвано. 


Примечание Термин ‹аккуратное размыкание» (orderly release) имеет неко- 
торое отношение к команде t. sndrel из АРІ ХТІ (совет 5), komo- 
рую также часто называют аккуратным размыканием в отличие 
от команды грубого размыкания (abortive release) t. snddis. Ho 
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путать их не стоит. Команда t. sndrel выполняет те же дей- 
ствия, что и shutdown. Обе команды используются для акку- 
ратного размыкания соединения. 


Просто закрыть соединение в некоторых случаях недостаточно, поскольку 
могут быть потеряны еще не принятые данные. Помните, что, когда приложение 
закрывает соединение, недоставленные данные отбрасываются. 

Чтобы поэкспериментировать с аккуратным размыканием, запрограммируй- 
те клиент, который посылает серверу данные, а затем читает и печатает ответ сер- 
вера. Текст программы приведен в листинге 3.1. Клиент читает из стандартного 
входа данные для отправки серверу. Как только fgets вернет NULL, индицирую- 
щий конец файла, клиент начинает процедуру разрыва соединения. Параметр -с 
в командной строке управляет этим процессом. Если -с не задан, то программа 
shutdownc вызывает shutdown для закрытия передающего конца соединения. 
Если же параметр задан, то shutdownc вызывает CLOSE, затем пять секунд 
«спит» и завершает сеанс. 


Листинг 3. 1. Клиент для экспериментов с аккуратным размыканием 


shutdownc.c 
1 £include "etcp.h" 
2 int main( int argc, char **argv ) 
3 { 
4 SOCKET s; 
5 fd set readmask; 
6 fd set allreads; 
7 int re; 
8 int len; 
9 int c; 
10 int closeit = FALSE; 
11 int err = FALSE; 
12 char lin[ 1024 ]; 
13 char lout[ 1024 ]; 


14 INIT(); 

15 opterr - FALSE; 

16 while ( ( c = getopt( argc, argv, "c" ) ) !- EOF ) 
17 ( 

18 switch( c ) 

19 { 

20 case 'c' 

21 closeit = TRUE; 

22 break; 

23 case '?' 

24 err - TRUE; 

25 ) 

26 ) 

27 if ( err || argc - optind != 2 ) 

28 error( 1, 0, "Порядок вызова: %s [-c] хост порт\п", 


29 program name ); 
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30 S = tcp client( argv[ optind ], argv[ optind + 1 ] ); 


31 FD ZERO( &allreads ); 
32 FD.SET( 0, &allreads ); 
33 FD SET( s, &allreads ); 


34 for ( ;; ) 
35 ( 
36 readmask = allreads; 
37 rc = select( S + 1, &readmask, NULL, NULL, NULL ); 
38 if (rc <= 0) 
39 error( 1, errno, "ошибка: select вернул ($d)", rc ); 
40 if ( FD ISSET( s, &readmask ) ) 
41 { 
42 rc = recv( s, lin, sizeof( lin ) - 1, 0 ); 
43 if (rc «0) 
44 error( 1, errno, "ошибка вызова recv" ); 
45 if (rc == 0 ) 
46 error( 1, 0, "сервер отсоединился\п" ); 
47 lin[ rc J = '\0'; 
48 if ( fputs( lin, stdout ) == EOF ) 
49 error( 1, errno, "ошибка вызова fputs" ); 
50 ) 
51 if ( FD ISSET( 0, &readmask ) ) 
52 { 
53 if ( fgets( lout, sizeof( lout ), stdin ) == NULL ) 
54 { 
55 FD CLR( 0, &allreads ); 
56 if ( closeit ) 
57 { 
58 CLOSE( s ); 
59 sleep( 5 ); 
60 EXIT( 0 ); 
61 ) 
62 else if ( shutdown( s, 1 ) ) 
63 error( 1, errno, "ошибка вызова shutdown" ); 
64 ) 
65 else 
66 ( 
67 len = strlen( lout ); 
68 rc = send( s, lout, len, 0 ); 
69 if (reo D) 
70 error( 1, errno, "ошибка вызова send" ); 
71 ) 
72 } 
73 } 
74 } 
shutdownc.c 
Инициализация 


14-30 Выполняем обычную инициализацию клиента и проверяем, есть ли 
в командной строке флаг -с. 
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Обработка данных 

40-50 Если B TCP-cokere есть данные для чтения, программа пытается про- 
читать, сколько можно, но не более, чем помещается в буфер. При по- 
лучении признака конца файла или ошибки завершаем сеанс, в против- 
ном случае выводим все прочитанное на stdout., 


Примечание Обратите внимание на конструкцию sizeof( lin ) -1 в вызове 
гесу на строке 42. Вопреки всем призывам избегать переполне- 
ния буфера, высказанным в совете 11, в первоначальной версии 
этой программы было написано sizeof( lin), что привело 
к записи за границей буфера в операторе 


lin[ rc ] = '\0:; 


в строке 47. 


53-64 Прочитав из стандартного входа EOF, вызываем либо shutdown, либо 
CLOSE в зависимости от наличия флага -c. 
65-71 В противном случае передаем прочитанные данные серверу. 


Можно было бы вместе с этим клиентом использовать стандартный системный 
сервис эхо-контроля, но, чтобы увидеть возможные ошибки и ввести некоторую за- 
держку, напишите собственную версию эхо-сервера. Ничего особенного в програм- 
ме tcpecho.c нет. Она только распознает дополнительный аргумент в командной 
строке, при наличии которого программа «спит» указанное число секунд между 
чтением и записью каждого блока данных (листинг 3.2). 

Сначала запустим клиент shutdownc с флагом -c, чтобы он закрывал сокет 
после считывания EOF из стандартного ввода. Поставим в сервере Е cpecho задерж- 
Ку на 4 с перед отправкой назад только прочитанных данных: 


bsd: $ tcpecho 9000 4 & 


[1] 3836 

bsd: $ shutdownc -c localhost 9000 

datal Эти три строки были введены 
data2 подряд максимально быстро 
^D 

tcpecho: ошибка вызова send: Broken pipe (32) Спустя 4 c 


после отправки "datal". 


Листинг 3.2. Эхо-сервер на базе ТСР 


tcpecho.c 
1 $include "etcp.h" 


2 int main( int argc, char **argv ) 


dest 

4 SOCKET s; 

5 SOCKET s1; 

6 char buf[ 1024 ]; 
7 int rc; 
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8 int пар = 0; 


9 ІМІТ(); 
10 if ( агас == ) 
11 пар = atoi( argv[ 2 ] ); 


12 в = tcp server( NULL, argv[ 1 ] ); 

13 s1 = accept( s, NULL, NULL ); 

14 if ( l!isvalidsock( s1 ) ) 

15 error( 1, errno, "ошибка вызова accept" ); 

16 signal( SIGPIPE, SIG IGN ); /* Игнорировать сигнал SIGPIPE. */ 
17 for ( ;;) 


18 { 

19 rc = recv( 51, buf, sizeof( buf ), 0); 

20 if (кс == 0) 

21 error( 1, 0, "клиент отсоединился\п" ); 
22 if (тс « 0) 

23 error( 1, errno, "ошибка вызова гесу" ); 
24 if ( nap ) 

25 Sleep( nap ); 

26 rc = send( s1, buf, rc, 0 ); 

27 if dqrsg s 

28 error( 1, errno, "ошибка вызова send" ); 
29 } 

30 } 


tcpecho.c 


Затем нужно напечатать две строки datai и data2 и сразу вслед за ними Ha- 
жать комбинацию клавиш Ctrl+D, чтобы послать программе shutdownc конец 
файла и вынудить ее закрыть сокет. Заметьте, что сервер не вернул ни одной стро- 
ки. В напечатанном сообщении tcpecho об ошибке говорится, что произошло. 
Когда сервер вернулся из вызова sleep и попытался отослать назад строку data1, 
он получил RST, поскольку клиент уже закрыл соединение. 


Примечание Как объяснялось в совете 9, ошибка возвращается при записи 
второй строки (data2). Заметьте, что это один из немногих 
случаев, когда ошибку возвращает операция записи, а не чтения. 
Подробнее об этом рассказано в совете 15. 


В чем суть проблемы? Хотя клиент сообщил серверу о том, что больше не бу- 
дет посылать данные, но соединение разорвал до того, как сервер успел завершить 
обработку, в результате информация была потеряна. В левой половине рис. 3.2 по- 
казано, как происходил обмен сегментами. 

Теперь повторим эксперимент, но на этот раз запустим shutdownc без флага -с. 


bsd: $ tcpecho 9000 4 & 

[1] 3845 

bsd: $ sghutdownc localhost 9000 
datai 

data2 

^D 
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datal Спустя 4 с после отправки "datai". 
data2 Спустя 4 с после получения "datali". 
tcpecho: клиент отсоединился 

shutdownc: сервер отсоединился 


Наэтот раз все сработало правильно. Прочитав из стандартного входа признак кон- 
ца файла, shutdownc вызывает shutdown, сообщая серверу, что он больше не будет 
ничего посылать, но продолжает читать данные из соединения. Когда сервер tcpecho 
обнаруживает EOF, посланный клиентом, он закрывает соединение, в результате чего 
ТСР посылает все оставшиеся в очереди данные, а вместе с ними FIN. Клиент, полу- 
чив EOF, определяет, что сервер отправил все, что у него было, и завершает сеанс. 

Заметьте, что у сервера нет информации, какую операцию (shutdown или close) 
выполнит клиент, пока не попытается писать в сокет и не получит код ошибки или 
EOF. Как видно из рис. 3.1, оба конца обмениваются теми же сегментами, что 
и раньше, до того, как ТСР клиента ответил на сегмент, содержащий строку data1. 

Стоит отметить еще один момент. В примерах вы несколько раз видели, что, 
когда ТСР получает от хоста на другом конце сегмент FIN, он сообщает об этом 
приложению, возвращая нуль из операции чтения. Примеры приводятся в строке 
45 листинга 3.1 и в строке 20 листинга 3.2, где путем сравнения кода возврата recv 
с нулем проверяется, получен ли EOF. Часто возникает путаница, когда в ситуации 
подобной той, что показана в листинге 3.1, используется системный вызов select 
Когда приложение на другом конце закрывает отправляющую сторону соедине- 
ния, вызывая close или shutdown либо просто завершая работу, select возвра- 
щает управление, сообщая, что в сокете есть данные для чтения. Если приложение 
при этом не проверяет EOF, то оно может попытаться обработать сегмент нулевой 
длины или зациклиться, переключаясь между вызовами read и select. 

В сетевых конференциях часто отмечают, что «select свидетельствует о Ha- 
личии информации для чтения, но в действительности ничего не оказывается». 
В действительности хост на другом конце просто закрыл, как минимум, отправля- 
ющую сторону соединения, и данные, о присутствии которых говорит select, — 
это всего лишь признак конца файла. 


Резюме 


Вы изучили системный вызов shutdown и сравнили его с вызовом close. Tak- 
же рассказывалось, что с помощью shut down можно закрыть только отправляю- 
щую, принимающую или обе стороны соединения; и счетчик ссылок на сокет при 
этом изменяется иначе, чем при закрытии с помощью close. 

Затем было показано, как использовать shutdown для аккуратного размыка- 
ния соединения. Аккуратное размыкание - это последовательность разрыва соеди- 
нения, при которой данные не теряются. 


Совет 17. Подумайте о запуске своего приложения 
через inetd 


В операционной системе UNIX и некоторых других имеется сетевой супер- 
сервер inetd, который позволяет почти без усилий сделать приложение сетевым 
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shutdownc tcpecho shutdownc tcpecho 


data 1 data 1 


close shutdown 


pase c RES 
E 
=== 
на 


Соединение разомкнуто 
с помощью shutdown 


Рис. 3.1. Системные вызовы close и shutdown 


Кроме того, если есть всего один процесс, который прослушивает входящие соеди- 
нения и входящие ОРЮР-датаграммы, то можно сэкономить системные ресурсы. 

Обычно inetd поддерживает, по меньшей мере, протоколы ТСР и UDP а возмож- 
HO, и некоторые другие. Здесь будут рассмотрены только два первых. Поведение inetd 
существенно зависит OT того, с каким протоколом — ТСР или UDP - он работает. 


ТСР-серверы 


Для ТСР-серверов inetd прослушивает хорошо известные порты, ожидая за- 
проса на соединение, затем принимает соединение, ассоциирует с ним файловые 
дескрипторы stdin, stdout и stderr, после чего запускает приложение. Таким 
образом, сервер может работать с соединением через дескрипторы 0, 1 и 2. Если 
это допускается конфигурационным файлом inetd (/etc/inetd.conf), то inetd 
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продолжает прослушивать тот же порт. Когда в этот порт поступает запрос на но- 
вое соединение, запускается новый экземпляр сервера, даже если первый еще не 
завершил сеанс. Это показано на рис. 3.2. Обратите внимание, что серверу не 
нужно обслуживать нескольких клиентов. Он просто выполняет запросы одного 
клиента, а потом завершается. Остальные клиенты обслуживаются дополнитель- 
ными экземплярами сервера. 


inetd (parent) 


for (each service) 


( 
socket () 
bind() 
listen() 


select() 
S - accept() 
fork() 

close(s) 


inetd (child) 


for (open fd != s) 
close(fd) 
dup2 (5,0) 
dup2(s,1) 
dup2(s,2) 
close(s) 
exec () 


Server (child) 


Рис. 3.2. Действия inetd при запуске ТСР-сервера 


Применение inetd освобождает от необходимости самостоятельно устанав- 
ливать ТСР или ОЮР-соединение и позволяет писать сетевое приложение почти 
так же, как обычный фильтр. Простой, хотя и не очень интересный пример при- 
веден в листинге 3.3. 


Листинг 3.3. Программа rinumd для подсчета строк 


marci rlinumd.c 
1 #include <stdio.h> 
2 void main( void ) 


3 í 
4 int cnt = 0; 

5 char line[ 1024 ]; 

6 /* 

7 * Мы должны явно установить режим построчной буферизации, 

8 * так как фуниции из библиотеки стандартного ввода/вывода 
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9 * не считают сокет терминалом. */ 
10 setvbuf( stdout, NULL, | IOLBF, 0 ); 
2T while ( fgets( line, sizeof( line ), stdin ) != NULL ) 
12 printf( "%31: $s", ++cnt, line ); 
13 } 


rinumd.c 
По поводу этой программы стоит сделать несколько замечаний: 


о в тексте программы не упоминается ни о ТСР, ни вообще o сети. Это не 3Ha- 
чит, что нельзя выполнять связанные с сокетами вызовы (getpeername, 
[gs] etsockopt ит.д.), просто в этом не всегда есть необходимость. Нет ника- 
ких ограничений и на использование read H write. Кроме того, можно пользо- 
ваться вызовами send, гесу, sendto и recvfrom,kak если бы inetd не было. 

О режим буферизации строк приходится устанавливать самостоятельно, по- 
скольку стандартная библиотека ввода/вывода автоматически устанавлива- 
ет подобный режим только в том случае, если считает, что вывод произво- 
дится на терминал. Это позволяет обеспечить быстрое время реакции для 
интерактивных приложений; 

О стандартная библиотека берет на себя разбиение входного потока на строки. 
Об этом уже говорилось в совете 6; 

о предполагаем, что не будет строк длиннее 1023 байт. Более длинные строки 
будут разбиты на несколько частей, и у каждой будет свой номер; 


Примечание Этот факт, который указан в книге [Oliver 2000], служит еще 
одним примером того, как можно легко допустить ошибку пере- 
полнения буфера. Подробнее этот вопрос обсуждался в совете 11. 


О хотя это приложение тривиально, HO во многих «настоящих» ТСР-прило- 
жениях, например telnet, rlogin и ftp, используется такая же техника. 


Программа в листинге 3.3 может работать и как «нормальный» фильтр, и как 
удаленный сервис подсчета строк. Чтобы превратить ее в удаленный сервис, нуж- 
но только выбрать номер порта, добавить в файл /etc/services строку с именем 
сервиса и номером порта и включить B файл / etc/inetd.conf строку, описываю- 
щую этот сервис и путь к исполняемой программе. Например, если вы назовете 
сервис rlnum, исполняемую программу для него — rlnumd и назначите ему порт 
8000, то надо будет добавить в /etc/services строку 


rlnum 8000/tcp # удаленный сервис подсчета строк, 
ав /etc/inetd.conf — строку 
rlnum stream tcp nowait jcs /usr/home/jcs/rlnumd rlnumd. 


Добавленная в /etc/services строка означает, что сервис г1пит использует 
протокол ТСР по порту 8000. Смысл же полей в строке, добавленной в /etc/ 
inetd.conf, таков: 


О имя сервиса, как он назван B /etc/services. Это имя хорошо известного 
порта, к которому подсоединяются клиенты данного сервера. В вашем при- 
мере – rlnum; 


CAMEE создание эффективных сетевых программ 

О тип сокета, который нужен серверу. Для ТСР-серверов это stream, a для 
ОРР-серверов ~ dgranm. Поскольку здесь сервер пользуется протоколом ТСР 
указан stream; 

о протокол, применяемый с сервером, – Е ср или udp. В данном примере это t cp; 

О флаг wait/nowait. Для UDP-cepBepos его значение всегда wait, а для TCP- 
серверов — почти всегда nowait. Если задан флаг nowait, то inetd сразу 
после запуска сервера возобновляет прослушивание связанного с ним хоро- 
шо известного порта. Если же задан флаг wait, то inetd не производит ника- 
кой работы с этим сокетом, пока сервер He завершится. А затем он возобновляет 
прослушивание порта в ожидании запросов на новые соединения (для stream- 
серверов) или новых датаграмм (для dgram-cepBepoB). Если для stream-cepBe- 
ра задан флаг wait, TO inetd не вызывает accept для соединения, а переда- 
ет сокет, находящийся в режиме прослушивания, самому серверу, который 
должен принять хотя бы одно соединение перед завершением. Как отмечено 
в сообщении [Kacker 1998], задание флага wait для ТСР-приложения - это 
мощная, но редко используемая возможность. Здесь приводится несколько 
применений флага wait для ТСР-соединений: 


— в качестве механизма рестарта для ненадежных сетевых программ-де- 
монов. Пока демон работает корректно, он принимает соединения от 
клиентов, но если по какой-то причине демон «падает», то при следую- 
щей попытке соединения inetd ero рестартует; 

— как способ гарантировать одновременное подключение только одного 
клиента; 

— как способ управления многопоточным или многопроцессным приложе- 
нием, зависящим от нагрузки. В этом случае начальный процесс запус- 
кается inetd, а затем он динамически балансирует нагрузку, создавая 
по мере необходимости дополнительные процессы или потоки. При 
уменьшении нагрузки, потоки уничтожаются, а в случае длительного 
простоя завершает работу и сам процесс, освобождая ресурсы и возвра- 
щая прослушивающий сокет inetd. 


В данном примере задан флаг nowait, как и обычно для ТСР-серверов. 


о имя пользователя, с правами которого будет запущен сервер. Это имя долж- 
но присутствовать в файле /etc/passwd. Большинство стандартных серве- 
ров, прописанных B inetd.conf, запускаются от имени root, но это совер- 
шенно необязательно. Здесь в качестве имени пользователя выбрано jcs. 

О полный путь к файлу исполняемой программы. Поскольку r1numd находит- 
ся в каталоге пользователя jcs, задан путь /usr/home/jcs/rlnumd; 

О до пяти аргументов (начиная с argv [0] ), которые будут переданы серверу. По- 
скольку в этом примере у сервера нет аргументов, оставлен только argv [0]. 


Чтобы протестировать сервер, необходимо заставить inetd перечитать свой 
конфигурационный файл (в большинстве реализаций для этого нужно послать ему 
сигнал SIGHUP) и соединиться с помощью telnet: 


bsd: $ telnet localhost rlnum 
Trying 127.0.0.1... 
Connected to localhost 
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Escape character is "^]". 
hello 
1: hello 
world 
2: world 
^] 
telnet> quit 
Connection closed. 
bsd: $ 


UDP-cepBepbi 

Поскольку в протоколе UDP соединения не устанавливаются (совет 1), inetd 
нечего слушать. При этом inetd запрашивает операционную систему (с помощью 
вызова Select) о приходе новых датаграмм в порт ООР-сервера. Получив извеще- 
ние, inetd дублирует дескриптор сокета на stdin, stdout и stderr и запускает 
ООР-сервер. В отличие от работы c ТСР-серверами при наличии флага nowait, 
inetd больше не предпринимает с этим портом никаких действий, пока сервер He 
завершит сеанс. В этот момент он снова предлагает системе извещать его о новых 
датаграммах. Прежде чем закончить работу, серверу нужно прочесть хотя бы одну 
датаграмму из сокета, чтобы inetd не «увидел» то же самое сообщение, что и рань- 
ше. В противном случае он опять запустит сервер, войдя в бесконечный цикл. 

Пример простого ОРР-сервера, запускаемого через inetd, приведен в листинге 3.4. 
Этот сервер возвращает то, что получил, добавляя идентификатор своего процесса. 


Листинг 3.4. Простой сервер, реализующий протокол запрос-ответ 


udpechol.c 
1 #include "etcp.nh" 
2 int main( int argc, char **argv ) 
3 { 
4 struct sockaddr_in peer; 
5 int rc; 
6 int len; 
7 int pidsz; 
8 char buf[ 120 ]; 
9 pidsz = sprintf( buf, "%d: ", getpid() ); 
10 len = sizeof( peer ); 
11 rc = recvfrom( 0, buf + pidsz, sizeof( buf ) - pidsz, 0, 
12 ( struct sockaddr * )&peer, &len ); 
13 if ( rec <= 0) 
14 exit( 1 ); 
15 sendto( 1, buf, rc + pidsz, 0, 
16 ( struct sockaddr * )&peer, len ); 
17 exit( O ); 
18 ) 
udpechol.c 
updecho1 
9 Получаем идентификатор процесса сервера (PID) от операционной 


системы, преобразуем его в код АЗСП и помещаем в начало буфера вво- 
да/вывода. 
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10-14 Читаем датаграмму от клиента и размещаем ее в буфере после иденти- 
фикатора процесса. 
15-17 Возвращаем клиенту ответ и завершаем сеанс. 


Для экспериментов с этим сервером воспользуемся простым клиентом, код 
которого приведен в листинге 3.5. Он читает запросы из стандартного ввода, отсы- 
лает их серверу и печатает ответы на стандартном выводе. 


Листинг 3.5. Простой ЦОР-клиент 


udpclient.c 


1 £include "etcp.h" 

2 int main( int argc, char **argv ) 

В 

4 struct sockaddr. in peer; 

5 SOCKET s; 

6 int rc - 0; 

7 int len; 

8 char buf[ 120 J; 

9 INIT(); 

10 S = udp client( argv[ 1 ], argv[ 2 ], &peer ); 

11 while ( fgets( buf, sizeof( buf ), stdin ) !- NULL ) 
12 { 
13 rc = sendto( s, buf, strlen( buf ), 0, 
14 ( struct sockaddr * )&peer, sizeof( peer ) ); 
15 if (rc « 0) 
16 error( 1, errno, "ошибка вызова sendto" ); 
17 len = sizeof( peer ); 
18 rc = recvfrom( s, buf, sizeof( buf ) - 1, 0, 

19 ( struct sockaddr * )&peer, &len ); 
20 if (roe « 0) 
21 error( 1, errno, "ошибка вызова recvfrom" ); 


22 bufi re |= 'VXNQ's; 


23 fputs( buf, stdout ); 
24 ) 
25 EXIT( 0 ); 
26 } 
udpclient.c 
10 Вызываем функцию udp. client, чтобы она поместила B структуру 


peer адрес сервера и получила UDP-coxer. 

11-16 Читаем строку из стандартного ввода и посылаем ee в виде ООР-дата- 
граммы хосту и в порт, указанные в командной строке. 

17-21 Вызываем recvfrom для чтения ответа сервера и в случае ошибки 3a- 
вершаем сеанс. 

22-23 Добавляем в конец ответа двоичный нуль и записываем строку на стан- 
дартный вывод. 


Запуск приложения через inetd 


В отношении программы udpclient можно сделать два замечания: 


о в реализации клиента предполагается, что он всегда получит ответ от серве- 
ра. Как было сказано в совете 1, нет гарантии, что посланная сервером дата- 
грамма будет доставлена. Поскольку udpclient - это интерактивная про- 
грамма, ее всегда можно прервать и запустить заново, если она «зависнет» 
в вызове recvfrom. Но если бы клиент не был интерактивным, нужно было 
бы взвести таймер, чтобы предотвратить потери датаграмм; 


Примечание В сервере udpecho1 об этом не нужно беспокоиться, так как 
точно известно, что датаграмма уже пришла (иначе inetdme за- 
пустил бы сервер). Однако уже в следующем примере (листинг 3.6) 
приходится думать о потере датаграмм, так что таймер ас- 
социирован с recvfrom. 


о при работе с сервером udpecho1 не нужно получать адрес и порт отправите- 
ля, так как они уже известны. Поэтому строки 18 и 19 можно было бы заме- 
нить на: 


гс = recvfrom( s, buf, sizeof( buf ) - 1, 0, NULL, NULD ); 


Ho, как показано B следующем примере, иногда клиенту необходимо иметь 
информацию, с какого адреса сервер послал ответ, поэтому приведенные здесь 
ООР-клиенты всегда извлекают адрес. 

Для тестирования сервера добавьте в файл /etc/inetd.conf на машине bsd 
строку 


udpecho dgram udp wait jcs /usr/home/jcs/udpechod udpechod, 
ав файл /etc/services — строку 
udpecho 8001 /пар 


Затем переименуйте udpechol в udpechod и заставьте программу inetd nepe- 
читать свой конфигурационный файл. При запуске клиента udpclient на машине 
Sparc получается: 


зрагс: $ udpclient bsd udpecho 


one 
28685: one 
two 

28686: two 
three 

28687: three 
^C 

Sparc: $ 


Этот результат демонстрирует важную особенность UDP-cepBepoB: они обыч- 
но не ведут диалог с клиентом. Иными словами, сервер получает один запрос 
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и посылает один ответ. Для UDP-cepBepos, запускаемых через inetd, типичными 
будут следующие действия: получить запрос, отправить ответ, выйти. Выходить 
нужно как можно скорее, поскольку inetd не будет ждать других запросов, на- 
правленных в порт этого сервера, пока тот не завершит сеанс. 

Из предыдущей распечатки видно, что, хотя складывается впечатление, будто 
udpclient ведет с чаресћо1 диалог, в действительности каждый раз вызывается 
новый экземпляр сервера. Конечно, это неэффективно, но важнее то, что сервер не 
запоминает информации о состоянии диалога. Для udpechol1 это несущественно, 
так как каждое сообщение - это, по сути, отдельная транзакция. Но так бывает не 
всегда. Один из способов решения этой проблемы таков: сервер принимает сооб- 
щение от клиента (чтобы избежать бесконечного цикла), затем соединяется с ним, 
получая тем самым новый (эфемерный) порт, создает новый процесс и завершает 
работу. Диалог с клиентом продолжает созданный вновь процесс. 


Примечание Есть и другие возможности. Например, сервер мог бы обслужи- 
вать нескольких клиентов. Принимая датаграммы от несколь- 
ких клиентов, сервер амортизирует накладные расходы на свой 
запуск и не завершает сеанс, пока не обнаружит, что долго про- 
стаивает без дела. Преимущество этого метода в некотором 
упрощении клиентов за счет усложнения сервера. 


Чтобы понять, как это работает, внесите в код udpecho1 изменения, представ- 
ленные в листинге 3.6. 


Листинг 3.6. Вторая версия udpechod 


udpecho2.c 

1 #include "etcp.h" 

2 int main( int argc, char **argv ) 

3 { 

4 struct sockaddr, in peer; 

5 int s$; 

6 int rc; 

7 int len; 

8 int pidsz; 

9 char buf[ 120 ]; 

10 pids2 = sprintf( buf, "$d: ", getpid() ); 
11 len = sizeof( peer ); 
12 rc = recvfrom( 0, buf + pidsz, sizeof( buf ) - pidsz, 
13 0, ( struct sockaddr * )&peer, &len ); 

14 if ( rc € 0 ) 
15 exit( 1 ); 
16 S = socket( AF INET, SOCK DGRAM, 0 ); 
17 if ououwx-:0-.) 

18 exit( 1 ); 

19 if ( connect( s, ( struct sockaddr * )&peer, len ) < 0) 


20 exit( 1 ); 
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21 if ( fork() != 0) /* Ошибка или родительский процесс? */ 

22 exit( 0 ); 

23 /* Порожденный процесс. */ 

24 while ( strncmp( buf + pidsz, "done", 4 ) != 0) 

25 ( 

26 if ( write( s, buf, rc + pidsz ) < 0) 

27 break; 

28 pidsz = sprintf( buf, "%4: ", getpid() ); 

29 alarm( 30 ); 

30 rc = read( s, buf + pidsz, sizeof( buf ) - pidsz ); 

31 alarm( 0 ); 

32 if ( xoc « 0 ) 

33 break; 

34 ) 

35 exit( 0 ); 

36 ) 

udpecho2.c 

udpecho2 

10-15 Получаем идентификатор процесса, записываем его в начало буфера 
и читаем первое сообщение так же, как B udpechol. 

16-20 Получаем новый сокет и подсоединяем его к клиенту, пользуясь адре- 
сом в структуре peer, которая была заполнена при вызове recvfrom. 

21-22 Родительский процесс разветвляется и завершается. В этот момент 
inetd может возобновить прослушивание хорошо известного порта 
сервера в ожидании новых сообщений. Важно отметить, что потомок 
использует номер порта new, привязанный к сокету s в результате вы- 
зова connect. 

24-35 Затем посылаем клиенту полученное от него сообщение, только с добав- 


ленным в начало идентификатором процесса. Продолжаем читать сооб- 
щения от клиента, добавлять к ним идентификатор процесса-потомка 
и отправлять их назад, пока не получим сообщение, начинающееся со 
строки done. В этот момент сервер завершает работу. Вызовы alarm, ок- 
ружающие операцию чтения на строке 30, – это защита от клиента, KO- 
торый закончил сеанс, не послав done. В противном случае сервер Mor 
бы «зависнуть» навсегда. Поскольку установлен обработчик сигнала 
SIGALRM, UNIX завершает программу при срабатывании таймера. 


Переименовав новую версию исполняемой программы B udpechod и запустив 
ее, вы получили следующие результаты: 


зрагс: 


one 


28743: 


two 


28744: 


three 


$ udpclient bsd udpecho 
one 


two 
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28744: three 
done 

^C 

sparc: $ 


На этот раз, как видите, B первом сообщении пришел идентификатор родительс- 
кого процесса (сервера, запущенного inetd), а в остальных — один и тот же иденти- 
фикатор (потомка). Теперь вы понимаете, почему udpclient всякий раз извлекает 
адрес сервера: ему нужно знать новый номер порта (а возможно, и новый [Р-адрес, 
если сервер работает на машине с несколькими сетевыми интерфейсами), в кото- 
рый посылать следующее сообщение. Разумеется, это необходимо делать только для 
первого вызова recvfrom, но для упрощения здесь не выделяется особый случай. 


Резюме 


В этом разделе показано, как заставить приложение работать в сети, прило- 
жив совсем немного усилий. Демон inetd берет на себя ожидание соединений или 
датаграмм, дублирует дескриптор сокета Ha stdin, stdout и stderr и запускает 
приложение. После этого приложение может просто читать из stdin или писать 
в stdout либо stderr, не имея информации о TOM, что оно работает в сети. Pac- 
смотрен пример простого фильтра, в котором вообще нет кода, имеющего отноше- 
ние к сети. Но этот фильтр тем не менее прекрасно работает в качестве сетевого 
сервиса, если запустить его через inetd. 

Здесь также приведен пример ООР-сервера, который способен вести продол- 
жительный диалог с клиентами. Для этого серверу пришлось получить новый со- 
кет и номер порта, а затем создать новый процесс и выйти. 


Совет 18. Подумайте о том, чтобы хорошо 
известный номер порта назначался вашему 
серверу с помощью tcpmux 


Проектировщик сетевого сервера сталкивается с проблемой выбора номера 
для хорошо известного порта. Агентство по выделению имен и уникальных пара- 
метров протоколов Internet (Internet Assigned Numbers Authority — ТАМА) подраз- 
деляет все номера портов Ha три группы: «официальные» (хорошо известные), 3a- 
регистрированные и динамические, или частные. 


Примечание Термин «хорошо известный порт» используется в общем смыс- 
ле — как номер порта доступа к серверу. Строго говоря, хорошо 
известные порты контролируются агентством ГАМА. 


Хорошо известные — это номера портов в диапазоне от 0 до 1023. Они контро- 
лируются агентством IANA. Зарегистрированные номера портов находятся в диа- 
пазоне от 1024 до 49151. ТАМА не контролирует их, но регистрирует и публикует 
в качестве услуги сетевому сообществу. Динамические или частные порты имеют 
номера от 49152 до 65535. Предполагается, что эти порты будут использоваться 
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как эфемерные, но многие системы не следуют этому соглашению. Так, системы, 
производные or BSD, традиционно выбирают номера эфемерных портов из диа- 
пазона от 1024—5000. Полный список всех присвоенных [АМА и зарегистриро- 


ванных номеров портов можно найти на сайте Вр: / /www.si.edu/in-notes/iana/ 
assignment/port-numbers/. 


Проектировщик сервера может получить от [АМА зарегистрированный номер 
порта. 


Примечание Чтобы подать заявку на получение хорошо известного или за- 
регистрированного номера порта, зайдите ua Web-cmpauuuy 


http; /wxww.isi.edu/cgi-bin/iana/port-numbers.pl. 


Это, конечно, не помешает другим использовать TOT же номер, и рано или позд- 
но два сервера, работающие с одним и тем же номером порта, окажутся на одной 
машине. Обычно эту проблему решают, выделяя некоторый номер порта по умол- 
чанию, но позволяя задать другой в командной строке. 

Другое более гибкое решение, но применяемое реже, состоит в том, чтобы ис- 
пользовать возможность inetd (совет 17), которая называется мультиплексором 
портов ТСР (ТСР Port Service Multiplexor - TCPMUX). Сервис TCPMUX опи- 
сан в RFC 1078 [Lotter 1988]. Мультиплексор прослушивает порт 1 в ожидании 
ТСР-соединений. Клиент соединяется с TCPMUX и посылает ему строку с име- 
нем сервиса, который он хочет запустить. Строка должна завершаться символа- 
ми возврата каретки и перевода строки (<CR><LF>). Сервер или, возможно, 
ТСРМОХ посылает клиенту один символ: + (подтверждение) или — (отказ), за 
которым следует необязательное пояснительное сообщение, завершаемое после- 
довательностью <CR><LF>. Имена сервисов (без учета регистра) также хранят- 
ся в файле inetd.conf, но начинаются со строки tcpmux/, чтобы отличить их от 
обычных сервисов. Если имя сервиса начинаются со знака +, то подтверждение 
посылает ТСРМОХ, а не сервер. Это позволяет таким серверам, как r1numd (лис- 
тинг 3.3), которые проектировались без учета ТСРМИХ, все же воспользоваться 
предоставляемым им сервисом. 

Например, если вы захотите запустить сервис подсчета строк из совета 17 в ка- 
честве ТСРМОХ-сервера, To надо добавить в файл inetd.conf строку 


tcpmux/*rlnumd stream tcp nowait jcs /usr/jome/jcs/rinumd rlnumd 


Для тестирования заставьте inetd перечитать свой конфигурационный файл, 
а затем подсоединитесь к нему с помощью telnet, указав имя сервиса TCPMUX: 


bsd: $ telnet localhost tcpmux 
Trying 127.0.0.1 
Connected to localhost 
Escape character is "^]". 
rlnumd 
*-Go 
hello 
1: hello 
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world 

2: world 
^] 
telnet» quit 
Connection closed 
bsd: $ 


К сожалению, сервис ТСРМ ОХ поддерживается не всеми операционными CHCTe- 
мами и даже не всеми ОМХ-системами. Ho, с другой стороны, его реализация настоль- 
ко проста, что возможно написать собственную версию. Поскольку TCPMUX должен 
делать почти то же, что и inetd (за исключением мониторинга нескольких сокетов) 
заодно будут проиллюстрированы те идеи, которые лежат в основе inetd. Начнем 
с определения констант, глобальных переменных и функции main (листинг 3.7). 


Листинг 3.7. tepmux - константы, глобальные переменные и main 


tcpmux.c 

1 #1пс1чае "etcp.h" 

2 &define MAXARGS 10 /* Максимальное число аргументов сервера. */ 
3 4define MAXLINE 256 /* Максимальная длина строки B tcpmux.conf. */ 
4 4$define NSERVTAB 10 /* Число элементов в таблице service table. */ 
5 #define CONFIG "tcpmux.conf" 

6 typedef struct 

YE | 

8 int flag; 

9 char *service; 
10 char *path; 
11 char *args[ MAXARGS + 1 ]; 
12 } servtab_t; 

13 int 18; /* Прослушиваемый сокет. */ 
14 servtab t service table[( NSERVTAB + 1 ]; 

15 int main( int argc, char **argv ) 

16 ( 

17 struct sockaddr. in peer; 

18 int s; 

19 int peerlen; 
20 /* Инициализировать и запустить сервер tcpmux. */ 
21 INIT(): 
22 parsetab(í); 
23 switch ( argc ) 

24 { 

25 case 1: /* Все по умолчанию. */ 

26 ls = tcp server( NULL, "tcpmux" ); 

27 break; 

28 case 2: /* Задан интерфейс и номер порта. */ 

29 ls = Еср_вегуег( argv[ 1 ], "tcpmux" ); 


30 break; 
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31 case 3: /* Заданы все параметры. */ 

32 ls = tcp.server( argv[ 1 ], argv[ 2 ] ); 

33 break; 

34 default: 

35 error( 1, 0, "Вызов: $s [ интерфейс [ порт ] ]Mn'", 
36 program name ); 

37 } 


38 daemon( 0, 0); 
39 signal( SIGCHLD, reaper ); 


40 /* Принять соединения C портом tcpmux. */ 
41 for 4 ;; 2) 
42 ( 
43 peerlen = sizeof( peer ); 
44 S = accept( 15, ( struct sockaddr * )&peer, &peerlen ); 
45 if (s«0) 
46 continue; 
47 start server( s ); 
48 CLOSE( s ); 
49 ) 
50 ) 
tcpmux.c 
main 


6-12 Структура servtab t определяет тип элементов в таблице 
service table.lIloze flag устанавливается в TRUE, если подтверж- 
дение должен посылать t cpmux, а не сам сервер. 

22 В начале вызываем функцию parsetab, которая читает и разбирает 
файл tcpmux. conf и строит таблицу service table. Текст процеду- 
ры parsetab приведен в листинге 3.9. 

23-37 Данная версия Есрших позволяет пользователю задать интерфейс или 
порт, который будет прослушиваться. Этот код инициализирует сер- 
вер с учетом заданных параметров, а остальным присваивает значения 
по умолчанию. 


38 Вызываем функцию daemon, чтобы перевести процесс t cpmux в фоно- 
вый режим и разорвать его связь с терминалом. 
39 Устанавливаем обработчик сигнала SIGCHLD. Это не дает запускаемым 


серверам превратиться в «зомби» (и зря расходовать системные ресур- 
сы) при завершении. 


Примечание В некоторых системах функция signal — это интерфейс к сиг- 
налам со старой «ненадежной» семантикой. В этом случае надо 
пользоваться функцией sigaction, которая обеспечивает ce- 
мантику надежных сигналов. Обычно эту проблему решают пу- 
тем создания собственной функции signal, которая вызывает 
из себя s1gaction. Такая реализация приведена в приложении 1. 
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41-49 В этом цикле принимаются соединения с ёсртих и вызывается функ- 
ЦИЯ start, server, которая создает новый процесс с помощью fork 
и запускает запрошенный сервер с помощью ехес. 


Теперь надо познакомимся с функцией start, server (листинг 3.8). Именно 
здесь выполняются основные действия. 


Листинг 3.8. Функция start, server 


tcpmux.c 
1 static void start, server( int s ) 
2-4 
3 char line[ MAXLINE ]; 
4 servtab t *stp; 
5 int re; 
6 static char errl[] = "-не могу прочесть имя сервиса \г\п"; 
7 static char err2[] = "-неизвестный сервис\х\п"; 
8 static char err3[] = "-не могу запустить сервис\г\п"; 
9 static char ok[] = "+О0К\х\п"; 
10 rc = fork(); 
11 if reo) /* Ошибка вызова fork. */ 
12 { 
13 write( s, err3, sizeof( err3 ) - 1); 
14 return; 
15 } 
16 if ( rc != 0) /* Родитель. */ 
17 return; 
18 /* Процесс-потомок. */ 
19 CLOSE( 1s ); /* Закрыть прослушивающий сокет. */ 


20 alarm( 10 ); 

21 rc = readcrlf( s, line, sizeof( line ) ); 
22 alarm( 0 ); 

23 if (rc <= 0) 


24 { 

25 write( s, erri, sizeof( err1 ) - 1); 

26 EXIT( 1 ); 

27 } 

28 for ( stp = service table; stp-»service; ѕір++ ) 
29 if ( strcasecmp( line, stp-»service ) == 0) 
30 break; 

31 if ( !stp-»service ) 

32 { 

33 write( s, err2, sizeof( err2 ) - 1}; 

34 EXIT( 1 ); 

35 ) 


36 if ( stp-»flag ) 
37 if ( wrltel s, ok, sizeof( ok ) «1 «€ 9 
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38 EXIT( 1 75 

39 dup2( s, 0 ); 

40 dup2l s, 1 ); 

41 dup2( s, 2); 

42 CLOSE( s ); 

43 execv( stp-»path, stp-»args ); 

44 write( 1, err3, sizeof( err3 ) - 1); 

45 EXIT( 1 3; 

46 ) 

tcpmux.c 
start server 

10-17 Сначала c помощью системного вызова fork создаем новый процесс, 
идентичный своему родителю. Если £ork завершился неудачно, TO по- 
сылаем клиенту сообщение об ошибке и возвращаемся (раз £ork не от- 
работал, то процесса-потомка нет, и управление возвращается в функ- 
цию main родительского процесса). Если fork завершился нормально, 
то это родительский процесс, и управление возвращается. 

19-27 В созданном процессе закрываем прослушивающий сокет и из подсо- 
единенного сокета читаем имя сервиса, которому нужно запустить 
клиент. Окружаем операцию чтения вызовами alarm, чтобы завер- 
шить работу, если клиент так и не пришлет имя сервиса. Если функ- 
ЦИЯ readcrlf возвращает ошибку, посылаем клиенту сообщение и 3a- 
канчиваем сеанс. Текст readcrlf приведен ниже в листинге 3.10. 

28-35 Ищем в таблице service table имя запрошенного сервиса. Если оно 
отсутствует, то посылаем клиенту сообщение об ошибке и завершаем 
работу. 

36-38 Если имя сервиса начинается со знака +, посылаем клиенту подтверж- 
дение. В противном случае даем возможность сделать это серверу. 

39-45 С помощью системного вызова dup дублируем дескриптор сокета на stdin, 


stdout и stderr, после чего закрываем исходный сокет. И, наконец, 
подменяем процесс процессом сервера с помощью вызова execv. После 
этого запрошенный клиентом сервер ~ это процесс-потомок. Если execv 
возвращает управление, то сообщаем клиенту, что не смогли запустить 
запрошенный сервер, и завершаем сеанс. 


В листинге 3.9 приведен текст подпрограммы parsetab. Она выполняет про- 
стой, но несколько утомительный разбор файла Е српих . conf. Файл имеет следу- 
ющий формат: 


имя_сервиса путь аргументы 


Листинг 3.9. Функция parsetab 


Ua CO BO L2 


tcpmux.c 


static void parsetab( void ) 
{ 


FILE *fp; 
servtab t *stp - service table; 
char *ср; 
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6 int i; 
7 int lineno; 
8 char line[ MAXLINE ]; 


9 fp = fopen( CONFIG, "r" ); 
10 if ( fp == NULL ) 


11 error( 1, errno, "He могу открыть %8", CONFIG ); 

12 lineno = 0; 

13 while ( fgets( line, sizeof( line ), fp ) !* NULL ) 

14 ( 

15 1іпепо++; 

16 if ( line[ strlen( line ) - 1] != '\һ') 

17 error( 1, 0, "строка %d слишком длинная\п", lineno ); 
18 if ( stp >= service table + NSERVTAB ) 

19 error( 1, 0, "слишком много строк B tcpmux.confMn" ); 
20 cp = strchr( line, '#' ); 

21 if ( ср != NULL ) 

22 *cp = '\0'; 

23 ср = strtok( line, " \Е\п" ); 

24 if ( cp == NULL ) 

25 continue; 

26 if ( *cp == '+' ) 

27 { 

28 stp->flag = TRUE; 

29 ср++; 

30 if ( жер == 'NX0* || strchr( " \t\n", *op y != NULL ) 
31 error( 1, 0, "строка %а: пробел после '*'Mn", 
32 lineno ); 

33 } 

34 stp-»service = strdup( cp ); 

35 if ( stp-»service == NULL ) 

36 error( 1, 0, "не хватило памяти\п" ); 

37 ср = strtok( NULL, " NtMn" ); 

38 if ( cp == NULL ) 

39 error( 1, 0, "строка %d: не задан путь (%5) \п", 
40 lineno, stp-»service ); 

41 stp->path = strdup( cp ); 

42 if ( stp-»path -- NULL ) 

43 error( 1, 0, "не хватило памяти\п”“ ); 

44 for (1 = 0; i < MAXARGS; i++ ) 

45 { 

46 ср = strtok( NULL, " \t\n" ); 

47 if ( cp == NULL ) 

48 break; 

49 stp-»args[ і ] = strdup( cp ); 

50 if ( stp-»args[ i ] == NULL ) 

5] error( 1, 0, "He хватило памяти\п" ); 

52 } 

53 if ( i >= MAXARGS && strtok( NULL, " StMn" ) l= NULL ) 


54 error( 1, 0, "строка $d: слишком много аргументов (%5) \п", 
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55 lineno, stp-»service ); 
56 stp-»args[ i ] = NULL; 

57 stpt+; 

58 } 


59 stp->service = NULL; 
60 fclose ( fp ); 
61 } 
tcpmux.c 


Показанная в листинге 3.10 функция readcrlf читает из сокета по одному 
байту. Хотя это и неэффективно, но гарантирует, что будет прочитана только пер- 
вая строка данных, полученных от клиента. Все данные, кроме первой строки, 
предназначены серверу. Если бы вы буферизовали ввод, а клиент послал бы боль- 
ше одной строки, то часть данных, адресованных серверу, считывал бы t cpmux, 
и они были бы потеряны. 

Обратите внимание, что readcrlf принимает также и строку, завершающую- 
ся только символом новой строки. Это находится в полном соответствии с прин- 
ципом устойчивости [Postel 1981а], который гласит: «Подходите не слишком стро- 
го к тому, что принимаете, но очень строго — к тому, что посылаете». В любом 
случае как <CR><LF>, так и одиночный <LF> отбрасываются. 

Определение функции readcrlf такое же, как функций read, readline, 
теа@п и readvrec: 


#include "etcp.nh" 
int readcrlf( SOCKET s, char *buf, size t len ); 


Возвращаемое значение: число прочитанных байт или —1 в случае ошибки. 


Листинг 3. 10. Функция readcrif 


readcrlf.c 
int readcrlf( SOCKET s, char *buf, size t len ) 


1 

2 

3 char *bufx - buf; 
4 int rc; 

5 char c; 

6 char lastc 
7 

8 


0; 
while ( len > 0) 


9 if ( (rec = recv( s, &c, 1, 0) ) = 1) 
10 { 

11 /* 

12 * Если нас прервали, повторим, 

13 * иначе вернем EOF или код ошибки. 
14 Ay 

15 if ( rc « 0 && errno -- EINTR ) 


16 continue; 


162 | РТВ 


17 
18 
19 
20 
21 
22 
23 
24 
25 


26 
27 
28 
29 
30 
31 
32 


} 


return rc; 


if (c == 'Wn' 
( 
if ( lastc 
buf--; 
*buf = 


'NO'; 


'\r' ) 


/* 


return buf - bufx; 


) 


*buftt = 
lastc - 
len--; 

) 

set errno( 

return -1; 


EMSGSIZE 


)4 


Не включать «CR»«LF». 
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T 


readcrif.c 


И наконец рассмотрим функцию reaper (листинг 3.11). Когда сервер, запу- 
щенный с помощью C cpmux, завершает сеанс, UNIX посылает родителю (то есть 
tcpmux) сигнал SIGCHLD. При этом вызывается обработчик сигнала reaper, ко- 
торый, в свою очередь, вызывает waitpid для получения статуса любого из за- 
вершившихся потомков. В системе UNIX это необходимо, поскольку процесс-по- 
томок может возвращать родителю свой статус завершения (например, аргумент 
функции exit). 


Примечание 


В некоторых вариантах UNIX потомок возвращает и другую un- 


формацию. Так, в системах, производных от BSD, возвращается 
сводная информация о количестве ресурсов, потребленных завер- 
шившимся процессом и всеми его потомками. Во всех системах 
UNIX, по меньшей мере, возвращается указание на то, как завер- 
шился процесс: из-за вызова ехіі (передается также код возвра- 
та) илииз-за прерывания сигналом (указывается номер сигнала). 


Пока родительский процесс не заберет информацию о завершении потомка 
с помощью вызова wait или waitpid, система UNIX должна удерживать ту часть 
ресурсов, занятых процессом-потомком, в которой хранится информация о состо- 
янии. Потомки, которые уже завершились, но еще не передали родителю инфор- 
мацию о состоянии, называются мертвыми (defunct) или «зомби». 


Листинг 3.11. Функция геарег 


ль шв 


void reaper( 


( 


int waitstatus; 


while ( waitpid( 


int sig ) 


-1, 


&waitstatus, 


WNOHANG ) 


> 0 ) 


Есртих.с 


{;} 


tcpmux.c 
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Протестируйте t cpmux, создав файл tcpmux. conf из одной строки: 
*rlnum /usr/hone/jcs/rlnumd rinumd 


Затем запустите tcpmux Ha машине sparc, которая He поддерживает сервиса 
TCPMUX, и соединитесь с ним, запустив telnet на машине bsd. 


Sparc: # tcpmux 


bsd: $ telnet sparc tcpmux 
Trying 127.0.0.1 
Connected to sparc 
Escape character is '^]'. 
rlnumd 
*OK 
hello 

1: hello 
world 

2: world 
^] 
telnet> quit 
Connection closed 
bsd: $ 


Резюме 


Сервис TCPMUX, имеющийся на очень многих системах, помогает решить 
проблему выбора хороо известного номера порта сервера. Здесь реализована соб- 
ственная версия демона tcpmux, так что если в какой-то системе его нет, TO им MOX- 
но воспользоваться. 


Совет 19. Подумайте об использовании 
двух ТСР-соединений 


Во многих приложениях удобно разрешить нескольким процессам или пото- 
кам читать из ТСР-соединений и писать в них. Особенно распространена эта прак- 
тика в системе UNIX, где по традиции создается процесс-потомок, который, Ha- 
пример, пишет в ТТУ-соединение, тогда как родитель занимается чтением. 

Типичная ситуация изображена на рис. 3.3, где показан эмулятор терминала. 
Родительский процесс большую часть времени блокирован в ожидании ввода из 
ТТУ-соединения. Когда на вход поступают данные, родитель читает их и выво- 
дит на экран, возможно, изменяя на ходу формат. Процесс-потомок в основном 
блокирован, ожидая ввода с клавиатуры. Когда пользователь вводит данные, 
потомок выполняет необходимые преобразования и записывает данные в ТТУ- 
соединение. 

Эта стратегия удобна, поскольку позволяет автоматически мультиплексиро- 
вать ввод с клавиатуры и из ТТҮ-соединения и разнести логику преобразования 
кодов клавиш и форматирования вывода на экран по разным модулям. За счет это- 
го программа получается концептуально проще, чем в случае нахождения кода 
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Родитель 
(читатель) 
Потомок 
(писатель) 


Рис. 3.3. Два процесса, обслуживающие ТТУ-соединение 
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соединение 


Клавиатура 


в одном месте. В действительности, до появления в операционной системе меха- 
низма select это был единственный способ обработки поступления данных из 
нескольких источников. 


Архитектура с одним соединением 


Следует заметить, что ничего не изменится, если на рис. 3.3 вместо ТТУ-со- 
единения будет написано ТСР-соединение. Поэтому та же техника может приме- 
няться (и часто применяется) для работы с сетевыми соединениями. Кроме того, 
использование потоков вместо процессов почти не сказывается на ситуации, изоб- 
раженной на рисунке, поэтому этот метод пригоден и для многопоточной среды. 

Правда, есть одна трудность. Если речь идет о ТТУ-соединении, то ошибки при 
операции записи возвращаются самим вызовом write, тогда как в случае ТСР ошиб- 
ка, скорее всего, будет возвращена последующей операцией чтения (совет 15). 
В многопроцессной архитектуре процессу-читателю трудно уведомить процесс- 
писатель об ошибке. В частности, если приложение на другом конце завершается, 
то об этом узнает читатель, который должен как-то известить писателя. 

Немного изменим точку зрения и представим себе приложение, которое при- 
нимает сообщения от внешней системы и посылает их назад по ТСР-соединению. 
Сообщения передаются и принимаются асинхронно, то есть не для каждого вход- 
ного сообщения генерируется ответ, и не каждое выходное сообщение посылается 
в ответ на входное. Допустим также, что сообщения нужно переформатировать на 


mp 
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сообщений) соединение система 


Рис. 3.4. Приложение, обменивающееся сообщениями по ТСР-соединению 
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входе или выходе из приложения. Тогда представленная на рис. 3.4 архитектура 
многопроцессного приложения оказывается вполне разумной. 

На этом рисунке процесс х1п читает данные от внешней системы, накапливает 
их в очереди сообщений, переформатирует и передает главному процессу обработ- 
ки сообщений. Аналогично процесс xout приводит выходное сообщение к фор- 
мату, требуемому внешней системой, и записывает данные в ТСР-соединение. Глав- 
ный процесс пр обрабатывает отформатированные входные сообщения и генерирует 
выходные сообщения. Оставляем неспецифицированным механизм межпроцесс- 
ного взаимодействия (IPC) между тремя процессами. Это может быть конвейер, 
разделяемая память, очереди сообщений или еще что-то. Подробнее все возмож- 
ности рассмотрены в книге [Stevens 1999]. В качестве реального примера такого 
рода приложения можно было бы привести шлюз, через который передаются со- 
общения между системами. Причем одна из систем работает по протоколу TCP, 
а другая — по какому-либо иному протоколу. 

Если обобщить этот пример, учитывая дополнительные внешние системы 
с иными требованиями к формату сообщений, то становится ясно, насколько гиб- 
кие возможности предоставляет описанный метод. Для каждого внешнего хоста 
имеется свой набор коммуникационных процессов, работающих только с его со- 
общениями. Такая система концептуально проста, позволяет вносить изменения, 
относящиеся к одному из внешних хостов, не затрагивая других, и легко конфи- 
гурируется для заданного набора внешних хостов — достаточно лишь запустить 
свои коммуникационные P E для каждого хоста. 

Однако при этом остается нерешенной вышеупомянутая проблема: процесс- 
писатель не может получить сообщение об ошибке после операции записи. А иног- 
да у приложения должна быть точная информация о том, что внешняя система 
действительно получила сообщение, и необходимо организовать протокол под- 
тверждений по типу того, что обсуждался в совете 9. Это означает, что нужно либо 
создать отдельный коммуникационный канал между процессами xin и xout, либо 
Xin должен посылать информацию об успешном получении и об ошибках про- 
цессу пр, который, в свою очередь, переправляет их процессу хоче. То и другое 
усложняет взаимодействие процессов. 

Можно, конечно, отказаться от многопроцессной архитектуры и оставить все- 
го один процесс, добавив select для мультиплексирования сообщений. Однако 
при этом приходится жертвовать гибкостью и концептуальной простотой. 

Далее в этом разделе рассмотрим альтернативную архитектуру, при которой 
сохраняется гибкость, свойственная схеме на рис. 3.4, но каждый процесс самосто- 
ятельно следит за своим ТСР-соединением. 


Архитектура с двумя соединениями 


Процессы xin и xout на рис. 3.4 делят между собой единственное соединение 
с внешней системой, но возникают трудности при организации разделения ин- 
формации о состоянии этого соединения. Кроме того, с точки зрения каждого из 
процессов xin и Xout, это соединение симплексное, то есть данные передаются по 
нему только в одном направлении. Если бы это было не так, то xout «похищал» 
бы входные данные y хіп, а xin Mor бы исказить данные, посылаемые xout. 
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Решение состоит B том, чтобы завести два соединения с внешней системой — 
по одному для xin и xout. Полученная после такого изменения архитектура изоб- 
ражена на рис. 3.5. 


Входное 
соединение 


пр 
(обработчик 


Внешняя 


сообщений) система 


Выходное 
соединение 


Рис. 3.5. Приложение, обменивающееся сообщениями по двум ТСР-соединениям 


Если система не требует отправки подтверждений на прикладном уровне, 
то при такой архитектуре выигрывает процесс xout, который теперь имеет BO3- 
можность самостоятельно узнавать об ошибках и признаке конца файла, послан- 
ных партнером. С другой стороны, xout становится немного сложнее, поскольку 
для получения уведомления об этих событиях он должен выполнять операцию чте- 
ния. К счастью, это легко можно обойти с помощью вызова select. 

Чтобы это проверить, запрограммируем простой процесс хоче, который читает 
данные из стандартного ввода и записывает их в ТСР-соединение. Программа, по- 
казанная в листинге 3.12, с помощью вызова select ожидает поступления данных 
из соединения, хотя реально может прийти только EOF или извещение об ошибке. 


Листинг 3.12. Программа, готовая к чтению признака конца файла или ошибки 


xouti.c 


1 d$include "etcp.h" 


2 int main( int argc, char **argv ) 


fd set allreads; 
fd set readmask; 
SOCKET s$; 

int rc; 

char buf[ 128 ]; 


INIT(); 
$ = tcp client( argv[ 1 ], argv[ 2 ] ); 
FD ZERO( &allreads ); 
FD SET( s, &allreads ); 
FD SET( 0, &allreads ); 
for ЕУ) 
{ 
readmask = allreads; 
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17 rc = select( s + 1, &readmask, NULL, NULL, NULL ); 
18 if (rc <= 0) 
19 error( 1, rc ? errno : 0, "select вернул $d'", rc ); 
20 if ( FD ISSET( 0, &readmask ) ) 
21 { 
22 rc = read( 0, buf, sizeof( buf ) - 1); 
23 if (rec « 0) 
24 error( 1, errno, "ошибка вызова read" ); 
25 if ( send( s, buf, rc, 0) < 0) 
26 error( 1, errno, "ошибка вызова send" ); 
27 ) 
28 if ( FD ISSET( s, &readmask ) ) 
29 { 
30 rc = recv( s, buf, sizeof( buf ) - 1, 0); 
31 if (rc == 0) 
32 error( 1, 0, "сервер отсоединился\п" ); 
33 else if (rc « 0) 
34 error( 1, errno, "ошибка вызова гесу" ); 
35 else 
36 ( 
37 buf[ rc ] = '\0'; 
38 error( 1, 0, "неожиданный вход [%$]\п", buf ); 
39 ) 
40 ) 
41 ) 
42 } 
xouti.c 
Инициализация 


9-13 Выполняем обычную инициализацию, вызываем функцию tcp client 
для установки соединения и готовим select для извещения о наличии 
входных данных в стандартном вводе или в только что установленном 
ТСР-соединении. 


Обработка событий stdin 
20-27 Если данные пришли из стандартного ввода, посылаем их удаленному 
хосту через ТСР-соединение. 


Обработка событий сокета 

28-40 Если пришло извещение о наличии доступных для чтения данных в со- 
кете, то проверяем, это ЕОЕ или ошибка. Никаких данных по этому 
соединению не должно быть получено, поэтому если пришло что-то 
иное, то печатаем диагностическое сообщение и завершаем работу. 


Продемонстрировать работу xout 1 можно, воспользовавшись программой keep 
(листинг 2.30) в качестве внешней системы и простым сценарием на языке интер- 
претатора команд shell для обработки сообщений (mp на рис. 3.5). Этот сценарий 
каждую секунду выводит На stdout слово message и счетчик. 


MSGNO-1 
while true 
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ао 
echo message ŞMSGNO 
sleep 1 
MSGNO-"expr $MSGNO + 1" 
done 


Обратите внимание, что B этом случае xout 1 использует конвейер в качестве 
механизма IPC. Поэтому в таком виде программа xout 1 не переносится на плат- 
форму Windows, поскольку вызов select работает под Windows только для соке- 
тов. Можно было бы реализовать взаимодействие между процессами с помощью 
ТСР или ОПР, но тогда потребовался бы более сложный обработчик сообщений. 

Для тестирования xout 1 запустим сначала «внешнюю систему» в одном окне, 
а обработчик сообщений и xout1 - в другом. 


bsd: $ keep 9000 bsd: $ mp | xoutli localhost 9000 
message 1 
message 2 
message 3 
message 4 


^O "Внешняя система" xoutl: сервер отсоединился 
завершила работу Broken pipe 
bsd: $ bsd: $ 


Сообщение Broken pipe напечатал сценарий mp. При завершении программы 
xout1 конвейер между ней и сценарием закрывается. Когда сценарий пытается 3a- 
писать в него следующую строку, происходит ошибка, и сценарий завершается 
с сообщением Broken pipe. 

Более интересна ситуация, когда между внешней системой и приложением, 
обрабатывающим сообщения, необходим обмен подтверждениями. В этом случае 
придется изменить и xin, и xout (предполагая, что подтверждения нужны в обоих 
направлениях; если нужно только подтверждать внешней системе прием сообще- 
ний, то изменения надо внести лишь B xin). Разработаем пример только процесса- 
писателя (хоче). Изменения в хіп аналогичны. 

Новый процесс-писатель обязан решать те же проблемы, с которыми вы стол- 
кнулись при обсуждении пульсаций в совете 10. После отправки сообщения уда- 
ленный хост должен прислать нам подтверждение до того, как сработает таймер. 
Если истекает тайм-аут, необходима какая-то процедура восстановления после 
ошибки. В примере работа просто завершается. 

При разработке нового «писателя» xout2 вы не будете принимать сообщений 
из стандартного ввода, пока не получите подтверждения от внешней системы о том, 
что ей доставлено последнее ваше сообщение. Возможен и более изощренный под- 
ход с использованием механизма тайм-аутов, описанного в совете 20. Далее он 6y- 
дет рассмотрен, но для многих систем вполне достаточно той простой схемы, KO- 
торую будет применена. Текст xout2 приведен в листинге 3.13. 


Листинг 3. 13. Программа, обрабатывающая подтверждения 


xout2.C 
1 d&include "etcp.n" 


2 #define АСК 0х6/* Символ подтверждения АСК. */ 
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i 
{ 


nt main( 


fd_set 
fd_set 
fd_set 
struct 
struct 
SOCKET 
int гс 


int argc, char **argv ) 


allreads; 

readmask; 

sockonly; 

timeval tv; 

timeval *tvp = NULL; 
S; 


* 
ГД 


char buf[ 128 ]; 
const static struct timeval TO = (2, 0 ); 


INIT() 


. 
Li 


S = tcp client( argv[ 1 ], argv[ 2 ] ); 
FD ZERO( &allreads ); 


FD SET( s, &allreads ); 
Sockonly = allreads; 
FD SET( 0, &allreads ); 
readmask = allreads; 
for ( ;; ) 
{ 
rc = select( s + 1, &readmask, NULL, NULL, tvp ); 
if (rc<0) 
error( 1, errno, "ошибка вызова select" ); 
if (кс == 0) 
error( 1, 0, "тайм-аут при приеме сообщения\п" ); 
if ( FD ISSET( s, &readmask ) ) 
( 
rc - recv( s, buf, sizeof( buf ), 0 ); 
if (rc == 0) 
error( 1, 0, "сервер отсоединился\п" ); 
else if (гс < 0) 
error( 1, errno, "ошибка вызова recv" ); 
else if (тс != 1 || buf[ O ] != АСК ) 


error( 1, 0, "неожиданный вход [%с]\п", БЕГ 0 ] }; 
tvp = NULL; /* Отключить таймер */ 
readmask = allreads; /* и продолжить чтение из stdin. */ 


} 
if ( FD ISSET( 0, &readmask ) ) 
( 
rc = read( 0, buf, sizeof( buf ) ); 
if (re «0 ) 
error( 1, errno, "ошибка вызова read" ); 
if ( send( s, buf, rc, 0 ) <0) 
error( 1, errno, "ошибка вызова Send" ); 
tv - T0; /* Переустановить таймер. */ 
tvp - &tv; /* Взвести таймер */ 
readmask = sockonly; /* и прекратить чтение из Stdin. */ 
) 
) 


-xout2.c 
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Инициализация 

14-15 Стандартная инициализация ТСР-клиента. 

16-20 Готовим две маски для select: одну для приема событий из stdin 
и ТСР-сокета, другую для приема только событий из сокета. Вторая 
маска ѕоскоп1у применяется после отправки данных, чтобы не читать 
новые данные из stdin, пока не придет подтверждение. 


Обработка событий таймера 


26-27 Если при вызове select произошел тайм-аут (не получено вовремя под- 
тверждение), то печатаем диагностическое сообщение и завершаем сеанс, 


Обработка событий сокета 

28-39 Если пришло извещение о наличии доступных для чтения данных 
в сокете, проверяем, это EOF или ошибка. Если да, то завершаем рабо- 
ту так же, как в листинге 3.12. Если получены данные, убеждаемся, что 
это всего один символ АСК. Тогда последнее сообщение подтвержде- 
но, поэтому сбрасываем таймер, устанавливая переменную tvp в NULL, 
и разрешаем чтение из стандартного ввода, устанавливая маску readmask 
так, чтобы проверялись и сокет, и stdin. 


Обработка событий в stdin 

40-66 Получив событие stdin, проверяем, не признакли это конца файла. Если 
чтение завершилось успешно, записываем данные в ТСР-соединение. 

47-50 Поскольку данные только что переданы внешней системе, ожидается 
подтверждение. Взводим таймер, устанавливая поля структуры tv 
и направляя на нее указатель tvp. В конце запрещаем события stdin, 
записывая в переменную readmask маску sockonly. 


Для тестирования программы xout 2 следует добавить две строки 


if ( send( s1, "\006", 1, 0) < 0) /* N006 == АСК */ 
error( 1, errno, "ошибка вызова send" ); 


перед записью Ha строке 24 B исходном тексте Кеер.с (листинг 2.30). Если выпол- 
НИТЬ Te же действия, как и для программы xout 1, то получим тот же результат с тем 
отличием, что xout2 завершает сеанс, не получив подтверждения от удаленного хоста. 


Резюме 


В этом разделе обсуждалась идея об использовании двух соединений между 
приложениями. Это позволяет отслеживать состояние соединения даже тогда, 
когда чтение и запись производятся в разных процессах. 


Совет 20. Подумайте, не сделать ли приложение 
событийно-управляемым (1) 


В этом и следующем разделах будет рассказано об использовании техники со- 
бытийной управляемости в программировании TCP/IP. Будет разработан универ- 
сальный механизм тайм-аутов, позволяющий указать программе, что некоторое 


Событийно-управляемое приложение 


тт 


событие должно произойти до истечения определенного времени, и асинхронно 
приступить к обработке этого события в указанное время. Здесь рассмотрим реа- 
лизацию механизма таймеров, а в совете 21 вернемся к архитектуре с двумя соеди- 
нениями и применим его на практике. 

Разница между событийно-управляемым и обычным приложением хорошо 
иллюстрируется двумя написанными ранее программами: hb, client2 (листинги 
2.26 n 2.27) n tcprw (листинг 2.21). В tcprw поток управления последовательный: 
сначала из стандартного ввода читается строка и передается удаленному хосту, 
а затем от него принимается ответ и записывается на стандартный вывод. Обрати- 
те внимание, что нет возможности ничего принять от удаленного хоста, пока ожи- 
дается ввод из st din. Как вы видели, в результате можно не знать, что партнер за- 
вершил сеанс и послал ЕОЕ Ожидая также ответа от удаленного хоста, вы не 
можете читать новые данные H3 stdin. Это значит, что приложение, с точки зре- 
ния пользователя, слишком медленно реагирует. Кроме того, оно может «завис- 
нуть», если удаленный хост «падает» до того, как приложение ответило. 

Сравните это поведение с работой клиента hb, client2, который в любой 
момент способен принимать данные по любому соединению или завершиться 
по тайм-ауту. Ни одно из этих событий не зависит от другого, именно поэтому 
такая архитектура называется событийно-управляемой. 

Заметим, что клиента hb. client2 можно легко обобщить на большее число 
соединений или источников входной информации. Для этого существует механизм 
select, который позволяет блокировать процесс в ожидании сразу нескольких CO- 
бытий и возвращать ему управление, как только произойдет любое из них. В системе 
ОМІХ этот механизм, а также родственный ему вызов ро11, имеющийся в системах 
на базе SysV, – это единственный эффективный способ обработки асинхронных со- 
бытий в немногопоточной среде. 


Примечание До недавнего времени считалось, что из соображений переноси- 
мости следует использовать select, а не poll, так как на плат- 
форме Windows, а равно в современных ИМХ-системах поддер- 
живается именно select, тогда как poll встречается обычно 
в реализациях на базе SysV. Однако некоторые большие серверные 
приложения (например, Web-cepeepw), поддерживающие очень 
много одновременных соединений, применяют механизм poll, 
так как он лучше масштабируется на большое число дескрипто- 
ров. Дело в том, что select ограничен фиксированным числом 
дескрипторов. Обычно их не больше 1024, но бывает и меньше. 
Так, в системе FreeBSD и производных от нее по умолчанию пре- 
дел равен 256. Для изменения значения по умолчанию нужно пере- 
собирать ядро, что неудобно, хотя и возможно. Но и пересборка 
ядра лишь увеличивает предел, а не снимает его. Механизм же 
ро11 не имеет встроенных ограничений на число дескрипторов. 
Следует также принимать во внимание эффективность. Ти- 
пичная реализация select может быть очень неэффективной 
при большом числе дескрипторов. Подробнее это рассматривает- 
ся в работе [Banga and Мови! 1998]. (В этой работе приводится 
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еще один пример возникновения трудностей при экстраполяции 
результатов, полученных в локальной сети, на глобальную. Эта 
тема обсуждалась в совете 12.) Проблема большого числа де- 
скрипторов стоит особенно остро, когда ожидается немного 
событий на многих дескрипторах, то есть первый аргумент — 
maxfd — велик, но с помощью FD SET было зарегистрировано 
всего несколько дескрипторов. Это связано с тем, что ядро долж- 
но проверить все возможные дескрипторы (0, ..., maxfd), чтобы 
понять, ожидаются ли приложением события хотя бы на одном 
из них. В вызове ро11 используется массив дескрипторов, 
с помощью которого ядру сообщается о том, в каких событиях за- 
интересовано приложение, так что этой проблемы не возникает. 


Итак, использование select или poll позволяет мультиплексировать He- 
сколько событий ввода/вывода. Сложнее обстоит дело с несколькими таймерами, по- 
скольку в вызове можно указать лишь одно значение тайм-аута. Чтобы решить эту 
проблему и создать тем самым более гибкое окружение для событийно-управляе- 
мых программ, следует разработать вариант вызова select — tselect. Хотя 
функции timeout и untimeout, связанные с tselect, построены по той же схе- 
ме, что и одноименные подпрограммы ядра UNIX, они работают в адресном npo- 
странстве пользователя и используют select для мультиплексирования ввода/ 
вывода и получения таймера. 

Таким образом, существуют три функции, ассоциированные с tselect. Прежде 
всего это сама tselect, которая применяется аналогично select для мульти- 
плексирования ввода/вывода. Единственное отличие в том, что у tselect нет 
параметра timeout (это пятый параметр select). События таймера задаются 
с помощью вызова функции timeout, которая позволяет указать длительность 
таймера и действие, которое следует предпринять при его срабатывании. Вызов 
untimeout отменяет таймер до срабатывания. 

Порядок вызова этих функций описан следующим образом: 


| int tselect( int maxfd, fd set *rdmask, fd set *wrmask, fd set *exmask ); | 
| Возвращаемое значение: число готовых событий, 0 — если событий нет, —1 -| 
|90: | 


unsigned int timeout( void ( *handler )( void * ), void *arg, int ms ); | 
Возвращаемое значение: идентификатор таймера для передачи unt imeout | 


| 

| 

| void untimeout( unsigned int timerid ); | 
L 


Когда срабатывает таймер, ассоциированный с вызовом timeout, вызывается 
функция, заданная параметром handler, которой передается аргумент, заданный 
параметром arg. Таким образом, чтобы организовать вызов функции retransmit 
через полторы секунды с целым аргументом sock, нужно сначала написать 


Событийно-управляемое приложение ЧТ! | | 1173 


timeout( retransmit, ( void * ) sock, 1500 ); 


а затем вызывать tselect. Величина тайм-аута ms задается B миллисекундах, HO 
надо понимать, что разрешающая способность системных часов может быть ниже, 
Для UNIX-cucreM типичное значение составляет 10 мс, поэтому не следует ожи- 
дать от таймера более высокой точности. 

Примеры использования + зе1ес* будут приведены далее, а пока рассмотрим 
ее реализацию. В листинге 3.14 приведено определение структуры tevent, t 
и объявления глобальных переменных. 


Листинг 3. 14. Глобальные данные для tselect 


{ 


o Jour buw N в 


ТЕ 


tselect.c 


#include "etcp.h" 
#define NTIMERS 25 


typedef struct tevent, t tevent t; 
struct tevent t 


tevent, t *next; 

struct timeval tv; 

void ( *func )( void * ); 
void *arg; 

unsigned int id; 


12 static tevent t *active = NULL; /* Активные таймеры. */ 
13 static tevent t *free list = NULL; /* Неактивные таймеры. */ 


tselect.c 


Объявления 


2 


3-11 


12 


13 


Константа МТТМЕВ$ определяет, сколько таймеров выделять за один раз. 
Сначала таймеров нет вовсе, поэтому при первом обращении к timeout 
будет выделено МТТМЕВ$ таймеров. Если все они задействованы и про- 
исходит очередное обращение к timeout, то выделяется еще МТТМЕВ$ 
таймеров. 

Каждый таймер представляет отдельную структуру типа tevent, t. 
Структуры связаны в список полем next. В поле tv хранится время 
срабатывания таймера. Поля func и arg предназначены для хранения 
указателя на функцию обработки события таймера (которая вызыва- 
ется при срабатывании) и ее аргумента. Наконец, идентификатор ак- 
тивного таймера хранится в поле id, 

Порядок расположения активных таймеров в списке определяется мо- 
ментом срабатывания. Глобальная переменная active указывает на 
первый таймер в списке. 

Неактивные таймеры находятся в списке свободных. Когда функции 
timeout нужно получить новый таймер, она берет ero из этого списка. Гло- 
бальная переменная free list указывает на начало списка свободных. 
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Далее изучим функцию timeout и подпрограммы выделения таймеров (лис- 


тинг 3.15). 
Листинг 3.15. Функции timeout и allocate timer 
tselect.c 
1 static tevent t *allocate timer( void ) 
2 { 
3 сеуепі 6 *tp; 
4 if ( free list == NULL ) /* нужен новый блок таймеров? */ 
5 ( 
6 free list - malloc( NTIMERS * sizeof( tevent t ) ); 
7 if ( free list == NULL ) 
8 error( 1, 0, "не удалось получить таймеры\п" ); 
9 for ( tp = free list; 
10 tp < free list + NTIMERS - 1; tp** ) 
11 tp-»next = tp + 1; 
12 tp-»next = NULL; 
13 ) 
14 tp = free list; /* Выделить первый. */ 
15 free list = tp-»next; /* Убрать ero из списка. */ 
16 return tp; 
17 ) 
18 unsigned int timeout( void ( *func )( void * ), void *arg, int ms ) 
19 ( 
20 tevent, t *tp; 
21 tevent, t *tcur; 
22 tevent, t **tprev; 
23 static unsigned int id = 1; /* Идентификатор таймера. */ 
24 tp = allocate timer(); 
25 tp-»-func = func; 
26 tp-»-arg = arg; 
27 if ( gettimeofday( &tp-»tv, NULL ) < 0 ) 
28 error( 1, errno, "timeout: ошибка вызова gettimeofday" ); 
29 tp-»tv.tv usec += ms * 1000; 
30 if ( tp-»tv.tv usec > 1000000 ) 
31 { 
32 tp-»tv.tv sec += tp-»tv.tv usec / 1000000; 
33 tp-»-tv.tv usec %= 1000000; 
34 ) 
35 for ( tprev = &active, tcur = active; 
36 tcur && !timercmp( &tp-»tv, &tcur-»tv, < ); /* XXX */ 
37 tprev - &tcur-»next, tcur - tcur-»next ) 
38 ES 
39 *tprev - tp; 
40 tp-»next = tcur; 
41 tp-»id = id**; /* Присвоить значение идентификатору таймера. */ 
42 return tp-»id; 
43 ) 


tselect.c 
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allocate timer 


4-13 


14-16 


Функция allocate timer вызывается из timeout для получения свобод- 
ного таймера. Если список свободных пуст, то из кучи выделяется память 
для МИМЕК$ структур tevent, t, H эти структуры связываются в список. 
Выбираем первый свободный таймер из списка и возвращаем его вы- 
зывающей программе. 


timeout 


24-26 
27-34 


35-38 


Получаем таймер и помещаем в поля func и arg значения переданных 
нам параметров. 

Вычисляем момент срабатывания таймера, прибавляя значение пара- 
метра ms к текущему времени. Сохраняем результат в поле Cv. 

Ищем в списке активных место для вставки нового таймера. Вставить 
таймер нужно так, чтобы моменты срабатывания всех предшествующих 
таймеров были меньше либо равны, а моменты срабатывания всех по- 
следующих — больше момента срабатывания нового. Ha рис. 3.6 показан 


В начале поиска 


Непосредственно 
перед вставкой 


Рис. 3.6. Список активных таймеров до и после поиска точки вставки 


ЛИШИ: создание эффективных сетевых программ 


27-34 


процесс поиска и значения переменных Е сиг и tprev. Вставляем новый 
таймер так, что его момент срабатывания t ew Удовлетворяет условию t, 
St Stew < tr Обведенный курсивом прямоугольник t „„ показывает 
позицию в списке, куда будет помещен новый таймер. Несколько стран- 
ное использование макроса timercmp в строке 36 связано с тем, что Bep- 
сия в файле winsock2.h некорректна и не поддерживает оператора >= 

Вставляем новый таймер в нужное место, присваиваем ему идентифи- 
катор и возвращаем этот идентификатор вызывающей программе. Воз- 
вращается идентификатор, а не адрес структуры tevent, t, чтобы из- 
бежать «гонки» (race condition). Когда таймер срабатывает, структура 
tevent, t возвращается в начало списка свободных. При выделении 
нового таймера будет использована именно эта структура. Если прило- 
жение теперь попытается отменить первый таймер, то при условии, что 
возвращается адрес структуры, а не индекс, будет отменен второй тай- 


"мер. Эту проблему решает возврат идентификатора. 


Идентификатор таймера, возвращенный в конце функции из листинга 3.15, 
используется функцией unt imeout (листинг 3.16). 


Листинг 3.16. Функция untimeout 


tselect.c 
1 void untimeout( unsigned int id ) 
2 { 
3 tevent t **tprev; 
4 tevent t *tcur; 
5 for ( tprev - &active, tcur - active; 
6 tcur && id != tcur-»id; 
7 tprev = &tcur-»next, tcur = tcur-»next ) 
B а 
9 if ( tcur == NULL ) 
10 ( 
11 error( 0, 0, 
12 "при вызове unt 1meout указан несуществующий таймер (%4) Nn", id); 
13 return; 
14 } 
15 *tprev = tcur->next; 
16 tcur-»next = free list; 
17 free list - tcur; 
18 } 
tselect.c 
Поиск таймера 
5-8 Ищем в списке активных таймер с идентификатором id. Этот цикл по- 
XOX на тот, что используется в timeout (листинг 3.15). 
9-14 | Если в списке нет таймера, который пытаемся отменить, то выводим 


диагностическое сообщение и выходим. 
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Отмена таймера 


15-17 Для отмены таймера исключаем структуру tevent, t из списка актив- 
ных и возвращаем в список свободных. 


Последняя из функций, работающих с таймерами, - это tselect (листинг 3.17) 


Листинг 3. 17. Функция tselect 


tselect.c 
int tselect( int maxpl, fd set *re, fd set *we, fd set *ee ) 
( 


1 

2 

3 fd_set rmask; 

4 fd_set wmask; 

5 fd set emask; 

6 struct timeval now; 
7 struct timeval tv; 

8 struct timeval *tvp; 
9 tevent. t *tp; 

10 int n; 


11 if ( re ) 


12 rmask = *re; 

13 if ( we) 

14 wmask = *we; 

15 if (ее ) 

16 emask = *ee; 

17 for ( ;; ) 

18 { 

19 if ( gettimeofday( &now, NULL ) < 0 ) 

20 error( 1, errno, "tselect: ошибка BB30Bagettimeofday" ); 
21 while ( active && !timercmp( &now, &active-»tv, < ) ) 
22 ( 

23 active-»func( active-»arg ); 

24 tp = active; 

25 active - active-»next; 

26 tp-»next = free list; 

27 free list = tp; 

28 ) 

29 if ( active ) 

30 ( 

31 tv.tv sec = active->tv.tv_sec - now.tv,.sec;; 
32 tv.tv usec = active->tv.tv_usec - now.tv_usec; 
33 if ( tv.tv_usec < 0 ) 

34 ( 

35 tv.tv usec += 1000000; 

36 tv.tv sec--; 

37 } 

38 tvp = асу; 
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40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 } 


else if ( re == NULL && ме == NULL && ее == NULD ) 


return 0; 
else 
tvp * NULL; 


n = select( maxpl, re, we, ee, tvp ); 
LI dono Do) 
return -1; 
if (п> 0) 
return n; 
if ( те) 
*re - rmask; 
if ( we ) 
*we - wmask; 
if ( ee) 
*ee - emask; 


tselect.c 


Сохранение масок событий 


11-16 


Поскольку при одном обращении к tselect может несколько раз вы- 
зываться select, сохраняем маски событий, передаваемых select. 


Диспетчеризация событий таймера 


19-28 


Хотя в первой структуре tevent, t, находящейся в списке активных 
таймеров, время срабатывания меньше или равно текущему времени, 
вызываем обработчик этого таймера, исключаем структуру из списка ак- 
тивных и возвращаем в список свободных. Как и в листинге 3.15, стран- 
ный вызов макроса timercmp обусловлен некорректной ero реализа- 
цией в некоторых системах. 


Вычисление времени следующего события 


29-39 


40-41 


42-43 


Если список активных таймеров не пуст, вычисляем разность между 
текущим моментом времени и временем срабатывания таймера в нача- 
ле списка. Это значение передаем системному вызову select. 

Если больше таймеров нет и нет ожидаемых событий ввода/вывода, 
TO tselect возвращает управление. Обратите внимание, что возвра- 
щается нуль, тем самым извещается об отсутствии ожидающих собы- 
тий. Семантика кода возврата отличается от семантики select. 

Если нет событий таймера, но есть события ввода/вывода, то устанав- 
ливаем tvp B NULL, чтобы select He вернулся из-за тайм-аута. 


Вызов select 


44-48 


Вызываем select, чтобы он дождался события. Если select заверша- 
ется с ошибкой, то возвращаем код ошибки приложению. Если select 
возвращает положительное значение (произошло одно или более со- 
бытий ввода/вывода), то возвращаем приложению число событий. По- 
скольку вызывали select, передавая указатели на маски событий, под- 
готовленные приложением, то биты событий в них уже установлены. 


Событийно-управляемое приложение 11| | | |179 


49-54 Если select вернул нуль, то сработал один или несколько таймеров. 
Поскольку в этом случае select обнулит все маски событий, установ- 
ленные приложением, восстановим их перед тем, как возвращаться 
к началу цикла, где вызываются обработчики таймеров. 


Для вставки и удаления таймеров из списка был использован линейный поиск. 
При небольшом числе таймеров это не страшно, но при увеличении их числа произ- 
водительность программы снижается, так как для поиска требуется O(n) операций, 
где n — число таймеров (для запуска обработчика события требуется время порядка 
O(1)). Вместо линейного поиска можно воспользоваться пирамидой [Sedgewick 
1998] — для вставки, удаления и диспетчеризации требуется O(log n) операций ~ или 
хэширующим кольцом таймеров (hashing timing wheel) [Varghese and Lacuk 1997]; 
при этом эффективность может достигать О(1) для всех трех операций. 

Заметим, что функция tselect не требует наличия ожидающих событий вво- 
да/вывода, поэтому ее вполне можно использовать только как механизм организа- 
ции тайм-аутов. В данном случае имеем следующие преимущества по сравнению 
с системным вызовом Sleep: 


о всистеме UNIX з1еер позволяет задерживать исполнение на интервал, крат- 
ный секунде, то есть разрешающая способность очень мала. В Windows такого 
ограничения ner. Во многих реализациях UNIX есть иные механизмы с более 
высокой степенью разрешения, однако они не очень распространены. Хоте- 
лось бы иметь механизм таймеров с высокой степенью разрешения, работаю- 
щий на возможно большем числе платформ. Поэтому в UNIX принято исполь- 
зовать для реализации высокоточных таймеров вызов select; 

O применение sleep или «чистого» select для организации нескольких тай- 
меров затруднительно, поскольку требует введения дополнительных струк- 
тур данных. В функции tselect все это уже сделано. 


К сожалению, в Windows функция tselect в качестве таймера работает не co- 
всем хорошо. В спецификации Winsock АРТ [WinSock Group 1997] говорится, 
что использование select в качестве таймера «неудовлетворительно и He име- 
ет оправданий». Хотя на это можно возразить, что «неудовлетворительность» — 
это когда системный вызов работает не так, как описано в опубликованной специ- 
фикации, все же придется придерживаться этой рекомендации. Тем не менее мож- 
но использовать функцию tselect и связанные с ней под Windows, только при 
этом следует указывать также и события ввода/вывода. 


Резюме 


В этом разделе обсуждены преимущества, которые дает управляемость при- 
ложения событиями. Разработан также обобщенный механизм работы с таймера- 
ми, не накладывающий ограничений на количество таймеров. 


Совет 21. Подумайте, не сделать ли приложение 
событийно-управляемым (2) 


Здесь будет продолжено обсуждение, начатое в совете 20, а также проиллюстри- 
ровано использование функции tselect в приложениях и рассмотрены некоторые 
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другие аспекты событийно-управляемого программирования. Вернемся к архи- 
тектуре с двумя соединениями из совета 19. 

Взглянув на программу xout2 (листинг 3.13), вы увидите, что она He управля- 
ется событиями. Отправив сообщение удаленному хосту, вы не возвращаетесь 
к чтению новых данных из стандартного ввода, пока не придет подтверждение. 
Причина в том, что таймер может сбросить новое сообщение. Если бы вы взвели 
таймер для следующего сообщения, не дождавшись подтверждения, то никогда не 
узнали бы, подтверждено старое сообщение или нет. 

Проблема, конечно, в TOM, что в программе xout 2 только один таймер и поэтому она 
не может ждать более одного сообщения в каждый момент, Воспользовавшись t select, 
вы сможете получить несколько таймеров из одного, предоставляемого select. 

Представьте, что внешняя система из совета 19 — это шлюз, отправляющий 
сообщение третьей системе по ненадежному протоколу. Например, он мог бы по- 
сылать датаграммы в радиорелейную сеть. Предположим, что сам шлюз не дает 
информации о том, было ли сообщение успешно доставлено. Он просто переправ- 
ляет сообщение и возвращает подтверждение, полученное от третьей системы. 

Чтобы в какой-то мере обеспечить надежность, новый писатель xout3 повторно 
посылает сообщение (но только один раз), если в течение определенного времени не 
получает подтверждения. Если и второе сообщение не подтверждено, xout прото- 
колирует этот факт и отбрасывает сообщение. Чтобы ассоциировать подтверждение 
с сообщением, на которое оно поступило, xout3 включает в каждое сообщение ne- 
кий признак. Конечный получатель сообщения возвращает этот признак в составе 
подтверждения. Начнем с рассмотрения секции объявлений xout3 (листинг 3.18). 


Листинг 3. 18. Объявления для программы хо! 3 


xout3.c 
1 #define АСК 0х6 /* Символ подтверждения АСК. */ 
2 $define MRSZ 128 /* Максимальное число неподтвержденных */ 
/* сообщений. */ 
3 #đefine T1 3000 /* Ждать 3 с до первого ACK */ 
4 #define T2 5000 /* и 5 с до второго АСК. */ 
5 #аеЕ1пе ACKSZ ( sizeof( u int32,t ) +1) 
6 typedef struct /* Пакет данных. */ 
7 { 
8 u int32 t len; /* Длина признака и данных. */ 
9 u int32 t cookie; /* Признак сообщения. */ 
10 char buf[ 128 ]; /* Сообщение. */ 
11 ) packet t; 
12 typedef struct /* Структура сообщения. */ 
13 ( 
14 packet t pkt; /* Указатель на coxpaHeHHoe сообщение. */ 
15 int id; /* Идентификатор таймера. */ 


16 ) msgrec t; 


17 static msgrec.t mr[ MRSZ ]; 
18 static SOCKET s; 


—————————————————————————————— M ——xout3.c 
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Объявления 


5 


6-11 


12-16 


17 


Признак, включаемый в каждое сообщение, - это 32-разрядный поряд- 
ковый номер сообщения. Подтверждение от удаленного хоста опреде- 
ляется как АЗСП-символ АСК, за которым следует признак подтверж- 
даемого сообщения. Поэтому константа ASCZ вычисляется как длина 
признака плюс 1. 

Тип packet. t определяет структуру посылаемого пакета. Поскольку 
сообщения могут быть переменной длины, в каждый пакет включена 
длина сообщения. Удаленное приложение может использовать это поле 
для разбиения потока данных на отдельные записи (об этом шла речь 
в совете 6). Поле 1en — это общая длина самого сообщения и признака. 
Проблемы, связанные с упаковкой структур, рассматриваются в заме- 
чаниях после листинга 2.15. 

Структура msgrec, t содержит структуру packet, t, посланную уда- 
ленному хосту. Пакет сохраняется на случай, если придется послать его 
повторно. Поле id ~ это идентификатор таймера, выступающего в роли 
таймера ретрансмиссии для этого сообщения. 

С каждым неподтвержденным сообщением связана структура msgrec t. 
Все они хранятся в массиве mr. 


Теперь обратимся к функции main программы xout3 (листинг 3.19). 


Листинг 3. 19. Функция тат программы хои 3 


xout3.c 


int main( int argc, char **argv ) 


fd set allreads; 

fd set readmask; 
msgrec t *mp; 

int rc; 

int mid; 

int cnt = 0; 

u int32 t msgid - 0; 
char ack[ ACKSZ |; 


INIT(); 
S = tcp client( argv[ 1 ], argv[ 2 ] ); 
FD ZERO( &allreads ); 
FD SET( s, &allreads ); 
FD SET( 0, &allreads ); 
for ( mp = mr; mp < mr + MRSZ; пр++ ) 
mp-»pkt.len = -1; 
Lor (ur 
{ 
readmask = alireads; 
rc - tselect( s * 1, &readmask, NULL, NULL ); 
if (тс < 0 ) 
error( 1, errno, "ошибка вызова tselect" ); 
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24 if ( rc == ) 
25 error( 1, 0, "tselect сказала, что нет событий\п" ); 
26 if ( FD ISSET( s, &readmask ) ) 
27 { 
28 rc = recv( s, ack + cnt, ACKSZ - cnt, 0 ); 
29 if (rc == 0) 
30 error( 1, 0, "сервер отсоединился\п" ); 
31 else if (тс < 0) 
32 error( 1, errno, "ошибка вызова recv" ); 
33 if ( ( cnt += rc ) < ACKSZ ) /* Целое сообщение? */ 
34 continue; /* Нет, еще подождем. */ 
35 cnt = 0; /* В следующий раз новое сообщение. */ 
36 if ( ack[ 0 ] != АСК ) 
37 { 
38 error( 0, 0, "предупреждение: неверное подтверждение\п" ) 
39 continue; 
40 ) 
41 memcpy( &mid, ack * 1, sizeof( u int32 t ) ); 
42 mp = findmsgrec( mid ); 
43 if (пр != NULL ) 
44 ( 
45 untimeout( пр->1а ); /* Отменить таймер. */ 
46 freemsgrec( mp ); /* Удалить сохраненное сообщение. */ 
47 ) 
48 } 
49 if ( FD ISSET( 0, &readmask ) ) 
50 ( 
51 mp = getfreerec(); 
52 rc = read( 0, mp-»pkt.buf, sizeof( mp->pkt.buf ) ); 
53 if € rc.e 0 ) 
54 error( 1, errno, "ошибка вызова read" ); 
55 mp-»pkt.buf[ rc ] = '\0'; 
56 mp-»pkt.cookie = msgidt+; 
57 mp-»-pkt.len = htonl( sizeof( u int32 t ) + rc ); 
58 if ( send( s, &mp-»pkt, 
59 2 * sizeof( ц int32 t ) + rc, 0) < 0) 
60 error( 1, errno, "ошибка вызова send" ); 
61 пр->іа = timeout( ( tofunc t )lost ACK, mp, T1 ); 
62 ) 
63 ) 
64 ) 
xout3.c 
Инициализация 


11-15 Так же, как и в программе xout 2, соединяемся с удаленным XOCTOM 
и инициализируем маски событий для tselect, устанавливая в них 
биты для дескрипторов stdin и сокета, который возвратила tcp, client. 

16-17 Помечаем все структуры msgrec, t как свободные, записывая в поле 
длины пакета —1. 


Событийно-управляемое приложение 


18-25 Вызываем tselect точно так же, как select, только не передаем по- 


следний параметр (времени ожидания). Если tselect возвращает 
ошибку или нуль, то выводим диагностическое сообщение и заверша- 
ем программу. В отличие от select возврат нуля из ёѕе1есі ~ свиде- 
тельство ошибки, так как все тайм-ауты обрабатываются внутри. 


Обработка входных данных из сокета 


26-32 


33-35 


36-40 


41-42 


При получении события чтения из сокета ожидаем подтверждение. 
В совете 6 говорилось о том, что нельзя применить recv в считывании 
ASCZ байт, поскольку, возможно, пришли еще не все данные. Нельзя 
воспользоваться и функцией типа readn, которая не возвращает управ- 
ления до получения указанного числа байт, так как это противоречило 
бы событийно-управляемой архитектуре приложения, — ни одно собы- 
тие не может быть обработано, пока readn не вернет управления. По- 
этому пытаемся прочесть столько данных, сколько необходимо для завер- 
шения обработки текущего подтверждения. В переменной cnt хранится 
число ранее прочитанных байт, поэтому ASCZ - cnt — это число недо- 
стающих байт. 

Если общее число прочитанных байт меньше ASCZ, то возвращаемся 
к началу цикла и назначаем tselect ожидание прихода следующей 
партии данных или иного события. Если после только что сделанного 
вызова recv подтверждение получено, TO сбрасываем cnt в нуль вожи- 
дании следующего подтверждения (к этому моменту не было прочита- 
но еще ни одного байта следующего подтверждения). 

Далее, в соответствии с советом 11, выполняем проверку правильнос- 
ти полученных данных. Если сообщение ~ некорректное подтвержде- 
ние, печатаем диагностическое сообщение и продолжаем работу. Возмож- 
но, здесь было бы правильнее завершить программу, так как удаленный 
хост послал неожиданные данные. 

Наконец, извлекаем из подтверждения признак сообщения, вызываем 
findmsgrec для получения указателя на структуру msgrec, t, ассоци- 
ированную с сообщением, и используем ее для отмены таймера, после 
чего освобождаем msgrec, t. Функции findmsgrec и freemsgrec при- 
ведены в листинге 3.20. 


Обработка данных из стандартного ввода 
21-57 Когда Е зе1есЕ сообщает о событии ввода из stdin, получаем струк- 


туру пзагес_ и считываем сообщение в пакет данных. Присваиваем 
сообщению порядковый номер, пользуясь счетчиком msgid, и сохра- 
няем его в поле cookie пакета. Обратите внимание, что вызывать 
ВЕ оп1 не нужно, так как удаленный хост не анализирует признак, 
а возвращает его без изменения. Записываем в поля пакета полную 
длину сообщения вместе с признаком. На этот раз вызываем htonl, 
так как удаленный хост использует это поле для чтения оставшейся 
части сообщения (совет 28). 


ANIMAE создание эффективных сетевых программ 


58-61 Посылаем подготовленный пакет удаленному хосту и взводим таймер 


ретрансмиссии, обращаясь к функции timeout. 


Оставшиеся функции программы xout3 приведены в листинге 3.20. 


Листинг 3.20. Вспомогательные функции программы хо! 3 


1 
2 
3 
4 
5 
6 
7 
8 


9 


10 
ti 
12 


13 
14 
15 
16 


17 
18 


19 
20 
21 
22 
23 
24 


25 
26 
27 
28 
29 


30 
31 
32 
33 
34 
35 
36 


37 } 


xout3.c 


msgrec t *getfreerec( void ) 


( 


} 


{ 


} 


msgrec_t *mp; 


for ( mp = mr; mp < mr + MRSZ; пр++ ) 
if ( mp->pkt.len == -1 ) /* Запись свободна? */ 
return mp; 
error( 1, 0, "getfreerec: исчерпан пул записей сообщений\п" ); 
return NULL; /* "Во избежание предупреждений компилятора. */ 


msgrec,t *findmsgrec( u int32 t mid ) 


msgrec t *mp; 


for ( пр = mr; пр < mr + MRSZ; пр++ ) 
if ( mp-»pkt.len != -1 && mp-»pkt.cookie == mid ) 
return mp; 
error( 0, 0, 
"findmsgrec: нет сообщения, соответствующего АСК $dWMn", mid ); 
return NULL; 


void freemsgrec( msgrec t *mp ) 


if ( mp-»pkt.len == -1 ) 
error( 1, 0, "freemsgrec: запись сообщения уже освобождена\п" ); 
mp-»pkt.len = -1; 


Static void drop( msgrec t *mp ) 


( 


} 


error( 0, 0, "Сообщение отбрасывается: $s", mp-»pkt.buf ) 
freemsgrec( mp ); 


static void lost ACK( msgrec t *mp ) 


( 


error( 0, 0, "Повтор сообщения: $s", mp-»pkt.buf ); 
if ( send( s, &mp-»pkt, 
sizeof( ч int32 t ) + ntohl( mp-»pkt.len ), 0) < 0) 
errorí( 1, errno, “потерян АСК: ошибка вызова send" ); 
пр->іа = timeout( ( tofunc t )drop, mp, Т2 ); 


xout3.C 
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getfreerec 


1-9 Данная функция ищет свободную запись в таблице mr. Просматрива- 
ем последовательно весь массив, пока не найдем пакет с длиной —1. 
Это означает, что запись свободна. Если бы массив mr был больше, TO 
можно было бы завести список свободных, как было сделано для запи- 
сей типа tevent, t в листинге 3.15. 


findmsgrec 

10-18 Эта функция почти идентичная get freerec, только Ha этот раз ищем 
запись с заданным признаком сообщения. 

freemsgrec 

19-24 Убедившись, что данная запись занята, устанавливаем длину пакета 
B —1, помечая тем самым, что теперь она свободна. 

drop 


25-29 Данная функция вызывается, если He пришло подтверждение Ha BTO- 
poe посланное сообщение (см. lost, ACK). Пишем в протокол диагнос- 
тику и отбрасываем запись, вызывая freemsgrec. 


lost АСК 


30-37 Эта функция вызывается, если не пришло подтверждение на первое 
сообщение. Посылаем сообщение повторно и взводим новый таймер ре- 
трансмиссии, указывая, что при его срабатывании надо вызвать функ- 
цию drop. 


Для тестирования xout3 напишем серверное приложение, которое случайным 
образом отбрасывает сообщения. Назовем этот сервер ext sys (сокращение oT external 
System — внешняя система). Его текст приведен в листинге 3.21. 


Листинг 3.21. Внешняя система 


extsys.c 
1 $include "etcp.h" 


2 *tdefine COOKIESZ 4 /* Так установлено клиентом. */ 


3 int main( int argc, char **argv ) 


4 { 

5 SOCKET s; 

6 SOCKET s1; 

7 int rc; 

8 char buf[ 128 ]; 
9 INIT(); 


10 $ = tcp server( NULL, argv[ 1 ] ); 

11 51 = accept( s, NULL, NULL ); 

12 if ( tisvalidsock( s1 ) ) 

13 error( 1, errno, "ошибка вызова accept" ); 
14 srand( 127 ); 

15 for ( ;; ) 
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16 { 
17 rc = readvrec( sl, buf, sizeof( buf ) ); 
18 if ( rc == ) 
19 error( 1, 0, "клиент отсоединился\п" ); 
20 if (rc «0) 
21 error( 1, errno, "ошибка вызова recv" ); 
22 if ( rand() $ 100 « 33 ) 
23 continue; 
24 write( 1, buf + COOKIESZ, rc - COOKIESZ ); 
25 memmove( buf * 1, buf, COOKIESZ ); 
26 buf[ 0] = '\006'; 
27 if ( send( s1, buf, 1 + COOKIESZ, 0 ) < 0) 
28 error( 1, errno, "ошибка вызова send" ); 
29 ) 
30 } 

extsys.c 
Инициализация 


9-14 Выполняем обычную инициализацию сервера и вызываем функцию 
srand для инициализации генератора случайных чисел. 


Примечание Функция rand из стандартной библиотеки С работает быстро 
и проста в применении, но имеет ряд нежелательных свойств. 
Хотя для демонстрации xout3 она вполне пригодна, но для cepo- 
езного моделирования нужно было бы воспользоваться более раз- 
витым генератором случайных чисел [Knuth 1998]. 


17-21 Вызываем функцию readvrec для чтения записи переменной длины, 
посланной xout3. 

22-23 Случайным образом отбрасываем примерно треть получаемых сообщений. 

24-28 Если сообщение ne отброшено, то выводим его на stdout, сдвигаем 
в буфере признак на один символ вправо, добавляем в начало символ 
АСК и возвращаем подтверждение клиенту. 


Вы тестировали xout3, запустив extsys в одном окне и воспользовавшись 
конвейером из совета 20 в другом (рис. 3.7). 
Можно сделать следующие замечания по поводу работы xout3: 


Q доставка сообщений по порядку не гарантирована. На примере сообщений 
17 и 20 на рис. 3.8 вы видите, что повторно посланное сообщение нарушило 
порядок; 

о можно было увеличить число повторных попыток, добавив счетчик попы- 
ток в структуру msgrec, t и заставив функцию lost, ACK продолжать по- 
пытки отправить сообщение до исчерпания счетчика; 

я легко модифицировать xout3 так, чтобы она работала по протоколу UDP, 
а не ТСР. Это стало бы первым шагом на пути предоставления надежного 
UDP-cepBuca (совет 8); 

О если бы приложение работало с большим числом сокетов (и использова- 
ло функцию tselect), то имело бы смысл вынести встроенный код readr 


Состояние TIME-WAIT 


111187 


в отдельную функцию. Такая функция могла бы получать на входе структу- 
ру, содержащую спе, указатель на буфер ввода (или сам буфер) и адрес фун- 
кции, которую нужно вызвать после получения полного сообщения; 

о в качестве примера xout3, пожалуй, выглядит чересчур искусственно, осо- 
бенно в контексте совета 19, но так или иначе она иллюстрирует, как можно 
решить задачу, часто возникающую на практике. 


bsd $ mp | xout3 localhost 9000 bsd $ extsys 9000 

xout3: Повтор сообщения: message 3 message 1 

xout3: Повтор сообщения: message 4 message 2 

xout3: Повтор сообщения: message 5 message 3 

xout3: Сообщение отбрасывается: message 4 message 6 

xout3: Сообщение отбрасывается: message 5 message 7 

xout3: Повтор сообщения: message 11 message 8 

xout3: Повтор сообщения: message 14 пеззаае 9 

xout3: Сообщение отбрасывается: message 11 message 10 

xout3: Повтор сообщения: message 16 message 12 

xout3: Повтор сообщения: message 17 message 13 

xout3: Сообщение отбрасывается: message 14 message 15 

xout3: Повтор сообщения: message 19 message 18 

xout3: Повтор сообщения: message 20 message 17 

xout3: Сообщение отбрасывается: message 16 message 21 

xout3: Сервер отсоединился message 20 

Broken pipe message 23 

bsd $ ^С сервер остановлен 
bsd $ 


Рис. 3.7. Демонстрация xout 3 


Резюме 


В этом и предыдущем разделах говорилось о событийно-управляемом про- 
граммировании и о том, как использовать вызов зе1ес® для реагирования на со- 
бытия по мере их поступления. В совете 20 разработана функция tselect, по- 
зволившая получить несколько логических таймеров из одного физического. Эта 
функция и используемые с ней функции timeout и unt imeout дают возможность 
задавать тайм-ауты сразу для нескольких событий, инкапсулируя внутри себя все 
сопутствующие этому детали. 

Здесь была использована функция tselect, чтобы усовершенствовать пример 
из совета 19. Применение tselect позволило задавать отдельные таймеры pe- 
трансмиссии для каждого сообщения, посланного ненадежному удаленному хосту 
через сервер-шлюз xout3. 


Совет 22. Не прерывайте состояние TIME-WAIT 
для закрытия соединения 


В этом разделе рассказывается о том, что такое состояние TIME-WAIT в прото- 
коле ТСР, для чего оно служит и почему не следует пытаться обойти его. 


EJE создание эффективных сетевых программ 


Поскольку состояние TIME- WAIT запрятано глубоко в недрах конечного ав- 
томата, управляющего работой ТСР, многие программисты только подозревают 
о его существовании и смутно представляют себе назначение и важность этого со- 
стояния. Писать приложения TCP/IP можно, ничего не зная о состоянии TIME- 
WAIT, но необходимо разобраться в странном, на первый взгляд, поведении при- 
ложения (совет 23). Это позволит избежать непредвиденных последствий. 

Рассмотрим состояние TIME-WAIT и определим, каково его место в работе 
ТСР-соединения. Затем будет рассказано о назначении этого состояния и его важ- 
ности, а также, почему и каким образом некоторые программисты пытаются обойти 
это состояние. В конце дано правильное решение этой задачи. 


Что это такое 


Состояние TIME-WAIT наступает в ходе разрыва соединения. Помните (совет 
7), что для разрыва ТСР-соединения нужно обычно обменяться четырьмя сегмен- 
тами, как показано Ha рис. 3.8. 

На рис. 3.8 показано соединение между двумя приложениями, работающими 
на хостах 1 и 2. Приложение на хосте 1 закрывает свою сторону соединения, при 
этом ТСР посылает сегмент FIN хосту 2. Хост 2 подтверждает FIN сегментом АСК 
и доставляет FIN приложению в виде признака конца файла EOF (предполагает- 
ся, что у приложения есть незавершенная операция чтения, ~ совет 16). Позже при- 
ложение на хосте 2 закрывает свою сторону соединения, посылая FIN хосту 1, ко- 
торый отвечает сегментом АСК. 


Хост 1 Xocr 2 
Приложение 
закрывает 
соединение FIN» 
Приложение 
закрывает 
соединение 
Соединение 
TIME-WAIT закрыто 
(2MSL) 
Соединение 
закрыто Рис. 3.8 


Разрыв соединения 


В этот момент хост 2 окончательно закрывает соединение и освобождает ре- 
сурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 не 
закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем B Te- 
чение двух максимальных продолжительностей существования сегмента (2MSL ~ 
maximum segment lifetime). 
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Примечание Максимальное время существования сегмента (MSL) — это мак- 
симальное время, в течение которого сегмент может оставать- 
ся в сети, прежде чем будет уничтожен. В каждой [Р-датаграмме 
есть поле TTL (time-to-live — время жизни). Это поле уменьшается 
на единицу каждым маршрутизатором, через который проходит 
датаграмма. Когда TTL становится равным нулю, датаграмма 
уничтожается. Хотя официально TTL измеряется в секундах, 
в действительности это поле почти всегда интерпретируется 
маршрутизаторами как счетчик промежуточных узлов. В RFC 
1812 [Baker 1995] этот вопрос обсуждается подробнее. 


Прождав время 2MSL, хост 1 также закрывает соединение и освобождает pe- 
сурсы. 
Относительно состояния TIME-WAIT следует помнить следующее: 


О обычно в состояние TIME-WAIT переходит только одна сторона — та, что 
выполняет активное закрытие; 


Примечание Под активным закрытием понимается отправка первого FIN. 
Считается, что вторая сторона при этом выполняет пассив- 
ное закрытие. Возможно также одновременное закрытие, когда 
обе стороны закрывают соединение примерно в одно время, 
поэтому посланные ими FIN одновременно находятся в сети. 
В этом случае активное закрытие выполняют обе стороны, так 
что обе переходят в состояние TIME-WAIT. 


о в КЕС 793 [Postel 19815] MSL определено равным 2 мин. При этом соедине- 
ние должно оставаться в состоянии TIME-WAIT в течение 4 мин. На прак- 
тике это обычно не так. Например, в системах, производных от BSD, MSL 
равно 30 с, так что состояние TIME-WAIT длится всего 1 мин. Можно встре- 
тить и другие значения в диапазоне от 30 с до 2 мин; 

О если в то время, когда соединение находится в состоянии TIME-WAITT, при- 
бывает новый сегмент, то таймер на 2MSL перезапускается. Это будет pac- 
сматриваться ниже. 


Зачем нужно состояние TIME-WAIT 
Состояние TIME-WAIT служит двум целям: 


О не дать соединению пропасть при потере последнего АСК, посланного ak- 
тивной стороной, в результате чего другая сторона повторно посылает FIN; 

О дать время исчезнуть «заблудившимся сегментам», принадлежащим этому 
соединению. 


Рассмотрим каждую из этих причин. В момент, когда сторона, выполняющая 
активное закрытие, готова подтвердить посланный другой стороной FIN, все дан- 
ные, отправленные другой стороной, уже получены. Однако последний АСК может 
потеряться. Если это произойдет, то сторона, выполняющая пассивное закрытие, 
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обнаружит тайм-аут и пошлет свой FIN повторно (так как не получила АСК на 
последний порядковый номер). 

А теперь посмотрим, что случится, если активная сторона не перейдет в состоя- 
ние TIME-WAIT, а просто закроет соединение. Когда прибывает повторно передан- 
ный FIN, у ТСР уже нет информации о соединении, поэтому он посылает в ответ 
RST (сброс), что для другой стороны служит признаком ошибки, а не нормаль- 
ного закрытия соединения. Но, так как сторона, пославшая последний АСК, все- 
таки перешла в состояние TIME-WAIT, информация о соединении еще хранит- 
ся, так что она может корректно ответить на повторно отправленный FIN. 

Этим объясняется и то, почему 2МЗГ-таймер перезапускается, если B состоя- 
нии TIME-WAIT приходит новый сегмент. Если последний АСК потерян, и дру- 
гая сторона повторно послала FIN, то сторона, находящаяся в состоянии TIME- 
WAIT, еще раз подтвердит ero и перезапустит таймер на случай, если и этот АСК 
будет потерян. 

Второе назначение состояния TIME-WAIT более важно. Поскольку ІР-дата- 
граммы могут теряться или задерживаться в глобальной сети, ТСР использует 
механизм подтверждений для своевременной повторной передачи неподтвержден- 
ных сегментов (совет 1). Если датаграмма просто задержалась в пути, но не поте- 
ряна, или потерян подтверждающий ее сегмент АСК, то после прибытия исход- 
ных данных могут поступить также и повторно переданные. ТСР в этом случае 
определяет, что порядковые номера поступивших данных находятся вне текущего 
окна приема, и отбрасывает их. 

А что случится, если задержавшийся или повторно переданный сегмент придет 
после закрытия соединения? Обычно это не проблема, так как ТСР просто отбросит 
данные и пошлет RST. Когда RST дойдет до хоста, отправившего задержавшийся сег- 
мент, то также будет отброшен, поскольку у этого хоста больше нет информации 
о соединении. Однако если между этими двумя хостами установлено новое соедине- 
ние с такими же номерами портов, что и раньше, то заблудившийся сегмент может 
быть принят как принадлежащий новому соединению. Если порядковые номера дан- 
ных в заблудившемся сегменте попадают в текущее окно приема нового соединения, 
то данные будут приняты, следовательно, новое соединение — скомпрометировано. 

Состояние TIME-WAIT предотвращает такую ситуацию, гарантируя, что два 
прежних сокета (два [Р-адреса и соответствующие им номера портов) повторно не 
используются, пока все сегменты, оставшиеся от старого соединения, не будут 
уничтожены. Таким образом, вы видите, что состояние TIME-WAIT играет важ- 
ную роль в обеспечении надежности протокола ТСР Без него ТСР не мог бы ra- 
рантировать доставку данных по порядку и без искажений (совет 9). 


Принудительная отмена состояния TIME-WAIT 


К сожалению, иногда можно досрочно выйти из состояния TIME-WAIT. Это 
называется принудительной отменой (TIME-WAIT assassination) и бывает случай- 
но или намеренно. 

Сначала посмотрим, как это может произойти случайно. По стандартам 
ВЕС 793, если соединение находится в состоянии TIME-WAIT и приходит RST, 
то соединение должно быть немедленно закрыто. Предположим, что имеется 
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соединение в состоянии TIME-WAIT и приходит старый сегмент-дубликат, кото- 
рый ТСР не принимает (например, потому, что порядковый номер оказался вне 
окна приема). ТСР посылает в ответ АСК, в котором указано, какой порядковый 
номер он ожидает (следующий за номером сегмента FIN, посланного другой сто- 
роной). Ноу хоста на другой стороне уже нет информации о соединении, поэтому 
на этот АСК он отвечает сегментом К$Т. Когда этот RST приходит хосту, у кото- 
poro соединение находится в состоянии TIME-WAIT, тот немедленно закрывает 
соединение, — состояние TIME-WAIT принудительно отменено. 

Эта ситуация описана в RFC 1337 [Braden 1992Ъ], где также рассматриваются 
трудности, сопряженные с принудительной отменой состояния TIME-WAIT. Опас- 
HOCTb COCTOHT B ВОЗМОЖНОСТИ «воскрешения» старого соединения (то есть появле- 
ния соединения с теми же двумя сокетами), что может привести к подтверждению 
старых данных, десинхронизации соединения с входом в бесконечный цикл и коши- 
бочному завершению нового соединения. 

Это легко предотвратить, изменив протокол ТСР так, чтобы в состоянии TIME- 
WAIT было разрешено игнорировать RST. Хотя такое изменение, рекомендован- 
Hoe в RFC 1337, официально не одобрено, тем не менее в некоторых стеках оно 
реализовано. 

Принудительно отменить состояние TIME-WAIT можно и намеренно. C по- 
мощью опции сокета SO, LINGER программист требует немедленного закрытия CO- 
единения даже в том случае, когда приложение выполняет активное закрытие. 
Этот сомнительный прием иногда рекомендуют применять, чтобы вывести «упав- 
ший» сервер из состояния TIME-WAIT и запустить его заново. Подробнее об этой 
проблеме и более правильном способе ее решения будет рассказано в совете 23. 
Корректно написанное приложение никогда не должно манипулировать состояни- 
ем TIME-WAIT, поскольку это неотъемлемая часть механизма обеспечения надеж- 
ности ТСР. 

Обычно, когда приложение закрывает соединение, вызов close или closesocket 
возвращается немедленно, даже если в буфере передачи еще есть данные. Разуме- 
ется, ТСР будет пытаться доставить эти данные, но приложение не имеет информа- 
ции, удалось ли это. Чтобы решить эту проблему, можно установить опцию сокета 
SO, LINGER. Для этого следует заполнить структуру linger и вызывать зеё зосКоре 
с параметром SO, LINGER. 

В большинстве ОМХ-систем структура linger определена B заголовочном 
файле /usr/include/sys/socket.h. В системе Windows она находится в файле 
Winsock2.h. В любом случае она выглядит так: 


Struct linger ( 
int 1 onoff; /* Включить/выключить опцию. */ 
int 1l, linger; /* Время задержки. */ 


Iz 


Если поле 1, onof f равно нулю, TO опция задержки отключается, и выбирает- 
ся поведение по умолчанию — вызов close или closesocket возвращается немед- 
ленно, а ядро продолжает попытки доставить еще не переданные данные. Если же 
] onoff не равно нулю, то работа зависит от значения поля 1_11пдек. Если 
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1_11пдег отлично от нуля, то считается, что это время, в течение которого ядро 
должно подождать отправки и подтверждения оставшихся в буфере передачи 
данных. При этом close или closesocket не возвращается, пока данные не Óy- 
дут доставлены или не истечет указанное время. 

Если к моменту завершения ожидания данные еще не доставлены, то с1озе 
или closesocket возвращает код EWOULDBLOCRK, и недоставленные данные могут 
быть потеряны. Если все данные уже доставлены, то оба вызова возвращают нуль. 


Прамечание К сожалению, семантика поля 1_11пдег зависит от реализа- 
ции. В Windows и некоторых реализациях UNIX это число се- 
кунд, на которое следует задержать закрытие сокета. В сис- 
темах, производных от BSD, это число тактов таймера (хотя 
в документации сказано, что это число секунд). 


Используя опцию SO LINGER таким способом, вы гарантируете, что данные 
будут доставлены уровню ТСР на удаленном хосте. Но они не обязательно будут 
прочитаны приложением. Более правильный способ добиться последнего — ис- 
пользовать процедуру аккуратного размыкания, описанную в совете 16. 

Если поле 1. linger равно нулю, то соединение разрывается. Это означает, что 
хосту на другом конце посылается RST, и соединение закрывается немедленно, не 
переходя в состояние TIME-WAIT. Это преднамеренная принудительная отмена 
состояния TIME-WAIT, о которой упоминалось выше. Как было сказано, это опас- 
ный прием, который в обычном приложении применять не следует. 


Резюме 


В этом разделе обсуждено состояние TIME-WAIT, которое часто понимают 
неправильно. Это состояние — важная часть механизма обеспечения надежности 
протокола ТСР, и попытки обойти его неверны. Преждевременный выход из со- 
стояния TIME-WAIT может быть обусловлен «естественным» стечением обсто- 
ятельств в сети или программой, которая манипулирует опцией SO LINGER. 


Совет 23. Сервер должен устанавливать опцию 
SO REUSEADDR 


B сетевых конференциях очень часто задают вопрос: «Когда сервер «падает» 
или нормально завершает сеанс, я пытаюсь его перезапустить и получаю ошибку 
«Address already in use». А через несколько минут сервер перезапускается нормаль- 
но. Как сделать так, чтобы сервер рестартовал немедленно?» Чтобы проиллюст- 
рировать эту проблему, напишем сервер эхо-контроля, который будет работать 
именно так (листинг 3.22). 


Листинг 3.22. Некорректный сервер эхо-контроля 


badserver.c 
1 £&include "etcp.h" 


2 int main( int argc, char **argv ) 
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3E 

4 struct sockaddr. in local; 

5 SOCKET в; 

6 SOCKET s1; 

7 int rc; 

8 char buf[ 1024 ]; 

9 INIT(); 
10 S = socket( PF INET, SOCK, STREAM, O0 ); 
11 if ( !isvalidsock( s ) ) 
12 error( 1, errno, "He могу получить сокет" ); 
13 bzero( &local, sizeof( local ) ); 


14 local.sin family = AF, INET; 

15 local.sin port - htons( 9000 ); 

16 local.sin addr.s addr = htonl( INADDR ANY ); 
17 if ( bind( s, ( struct sockaddr * )&local, 


18 sizeof( local ) ) < 0 ) 

19 error( 1, errno, "He могу привязать сокет" ); 
20 if ( listen( s, NLISTEN ) < 0 ) 

21 error( 1, errno, "ошибка вызова listen" ); 


22 sl = accept( s, NULL, NULL ); 
23 if ( !isvalidsock( s1 ) ) 


24 error( 1, errno, "ошибка вызова accept" ); 

25 for dore.) 

26 { 

27 rc = гесу( sl, buf, sizeof( buf ), 0); 

28 if (rc « 0) 

29 error( 1, errno, "ошибка вызова recv" ); 
30 if (rc == 0 ) 

31 error( 1, 0, "Клиент отсоединился\п" ); 

32 rc = send( s1, buf, rc, 0 ); 

33 if (тс < 0) 

34 error( 1, errno, "ошибка вызова send" ); 
35 } 

36 } 


badserver.c 


На первый взгляд, сервер выглядит вполне нормально, только номер порта 
«зашит» в код. Если запустить его в одном окне и соединиться с ним с помощью 
программы telnet, запущенной в другом окне, то получится ожидаемый результат. 
(Ha рис. 3.9 опущены сообщения telnet об установлении соединения.) 

Проверив, что сервер работает, останавливаете клиента, переходя в режим ко- 
манд telnet и вводя команду завершения. Обратите внимание, что если немед- 
ленно повторить весь эксперимент, то будет тот же результат. Таким образом, 
badserver перезапускается без проблем. 

А теперь проделайете все еще раз, но только остановите сервер. При попытке 
перезапустить сервер вы получите сообщение «Address already in use» (сообщение 
разбито на две строчки). Разница в том, что во втором эксперименте вы останови- 
ли сервер, а не клиент - рис. 3.10. 
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bsd $ badserver bsd $ teinet localhost 9000 
badserver: Клиент отсоединился | hello 

bsd $: badserver hello 

badserver: Клиент отсоединился | ^] 

bsd $ telnet» quit Клиент завершил сеанс. 


Connection closed 
Сервер перезапущен. 
bsd $ telnet localhost 9000 
world 
world 
^] 
telnet» quit Клиент завершил сеанс. 
Connection closed 
bsd $ 


Рис. 3.9. Завершение работы клиента 


bsd $ badserver bsd $ telnet localhost 9000 

^C Сервер остановлен hello again 

bsd $ badserver hello again 

badserver: Не могу привязать сокет: Connection closed by 
foreign host 

Address already in use (48) bsd $ 

bsd $ 


Рис. 3.10. Завершение работы сервера 


Чтобы разобраться, что происходит, нужно помнить о двух вещах: 


О состоянии TIME-WAIT протокола ТСР; 
о ТСР-соединение полностью определено четырьмя факторами (локальный 
адрес, локальный порт, удаленный адрес, удаленный порт). 


Как было сказано в совете 22, сторона соединения, которая выполняет актив- 
ное закрытие (посылает первый FIN), переходит в состояние TIME-WAIT и оста- 
ется в нем в течение 2MSL. Это первый ключ к пониманию того, что вы наблюда- 
ли в двух предыдущих примерах: если активное закрытие выполняет клиент, то 
можно перезапустить обе стороны соединения. Если же активное закрытие выпол- 
няет сервер, то его рестартовать нельзя. ТСР не позволяет это сделать, так как пре- 
дыдущее соединение все еще находится в состоянии TIME-WAIT. 

Если бы сервер перезапустился и с ним соединился клиент, то возникло бы 
новое соединение, возможно, даже с другим удаленным хостом. Как было сказа- 
но, ТСР-соединение полностью определяется локальными и удаленными адреса- 
ми и номерами портов, так что даже если с вами соединился клиент с того же уда- 
ленного. хоста, проблемы не возникнет при другом номере удаленного порта. 


Примечание Даже если клиент с того же удаленного хоста воспользуется 
тем же номером порта, проблемы может и не возникнуть. Тра- 
диционно реализация BSD разрешает такое соединение, если 
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только порядковый номер посланного клиентом сегмента SYN 
больше последнего порядкового номера, зарегистрированного со- 
единением, которое находится в состоянии TIME-WAIT. 


Возникает вопрос: почему ТСР возвращает ошибку, когда делается попытка 
перезапустить сервер? Причина не в ТСР который требует только уникальности 
указанных факторов, a в API сокетов, требующем двух вызовов для полного опре- 
деления этой четверки. В момент вызова bind еще неизвестно, последует ли за 
ним connect, и, если последует, то будет ли в нем указано новое соединение, или 
он попытается повторно использовать существующее. В книге [Torek 1994] ав- 
тор — и не он один — предлагает заменить вызовы bind, connect и listen одной 
функцией, реализующей функциональность всех трех. Это даст возможность ТСР 
выявить, действительно ли задается уже используемая четверка, не отвергая попы- 
ток перезапустить закрывшийся сервер, который оставил соединение в состоя- 
нии TIME-WAIT. К сожалению, элегантное решение Topeka не было одобрено. 

Но существует простое решение этой проблемы. Можно разрешить ТСР при- 
вязку к уже используемому порту, задав опцию сокета SO REUSEADDR. Чтобы mpo- 
верить, как это работает, вставим между строками 7 и 8 файла badserver.c строку 


const int on = 1; 
а между строками 12 и 13 – строки 


if ( setsockopt( s, SOL SOCKET, SO, REUSEADDR, &on, 
sizeof( on ) ) ) 
error( 1, errno, "ошибка вызова setsockopt" ); 


Заметьте, что вызов set sockopt должен предшествовать вызову bind. Если на- 
звать исправленную программу доодзегуег и повторить эксперимент (рис. 3.11), 
то получите такой результат: 


bsd $ goodserver bsd $ telnet localhost 9000 
^С Сервер остановлен. hello once again 
bsd $ hello once again 


Connection closed by foreign host 
Сервер перезапущен. 

bsd $ telnet localhost 9000 

hello one last time 

hello one last time 


Рис. 3.11. Завершение работы сервера, B котором используется опция SO REUSEADDR 


Теперь вы смогли перезапустить сервер, не дожидаясь выхода предыдущего 
соединения из состояния TIME-WAIT. Поэтому в сервере всегда надо устанавли- 
вать опцию сокета SO, REUSEADDR. Обратите внимание, что в предлагаемом Kapka- 
ce и в функции tcp, server это уже делается. 

Некоторые, B том числе авторы книг, считают, что задание опции SO. REUSEADDR 
опасно, так как позволяет ТСР создать четверку, идентичную уже используемой, 
и таким образом создать проблему. Это ошибка. Например, если попытаться создать 
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два идентичных прослушивающих сокета, то ТСР отвергнет операцию привязки, 
даже если вы зададите опцию SO. REUSEADDR: 


bsd $ goodserver & 

[1] 1883 

bsd $ goodserver 

goodserver: Не могу привязать сокет: Address already in use (48) 
bsd $ 


Аналогично если вы привяжете одни и Te же локальный адрес и порт к двум 
разным клиентам, задав $0, REUSEADDR, TO ріпа для второго клиента завершится 
успешно. Однако на попытку второго клиента связаться с тем же удаленным хос- 
том и портом, что и первый, ТСР ответит отказом. 

Помните, что нет причин, мешающих установке опции SO REUSEADDR в серве- 
ре. Это позволяет перезапустить сервер сразу после его завершения. Если же этого 
не сделать, то сервер, выполнявший активное закрытие соединения, не перезапус- 
тится. 


Прамечание B книге [Stevens 1998] отмечено, что с опцией SO. REUSEADDR cea- 
зана небольшая проблема безопасности. Если сервер привязывает 
универсальный адрес ТМАРОК_АМУ, как это обычно и делается, mo 
другой сервер может установить опцию SO REUSEADDR и привя- 
зать тот же порт, но с конкретным адресом, ‹похитив» тем 
самым соединение у первого сервера. Эта проблема действитель- 
но существует, особенно для сетевой файловой системы (NFS) 
даже в среде UNIX, поскольку NFS привязывает порт 2049 из 
открытого всем диапазона. Однако такая опасность существу- 
em не из-за использования NFS опции SO REUSEADDR, а потому 
umo это может сделать другой сервер. Иными словами, эта опас- 
ность имеет место независимо от установки SO. REUSEADDR, 
так что это не причина для отказа от этой опции. 


Следует отметить, что у опции SO REUSEADDR есть и другие применения. 
Предположим, например, что сервер работает на машине с несколькими сетевы- 
ми интерфейсами и ему необходимо иметь информацию, какой интерфейс кли- 
ент указал в качестве адреса назначения. При работе с протоколом ТСР это легко, 
так как серверу достаточно вызвать getsockname после установления соедине- 
ния. Но, если реализация TCP/IP не поддерживает опции сокета IP, RECVDSTADDR, 
то UDP-cepsep так поступить не может. Однако UDP-cepsBep может решить эту зада- 
чу, установив опцию SO REUSEADDR и привязав свой хорошо известный порт к KOHK- 
ретным, интересующим его интерфейсам, а универсальный адрес ТМАРОВ_АМУ — KO 
всем остальным интерфейсам. Тогда сервер определит указанный клиентом адрес 
по сокету, в который поступила датаграмма. 

Аналогичная схема иногда используется TCP- и ОРрР-серверами, которые XO- 
тят предоставлять разные варианты сервиса в зависимости от адреса, указанного 
клиентом. Допустим, вы хотите использовать свою версию tcpmux (совет 18) для 
предоставления одного набора сервисов, когда клиент соединяется с интерфейсом 
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по адресу 198.200.200.1, и другого – при соединении клиента с иным интерфей- 
сом. Для этого запускаете экземпляр tcpmux со специальными сервисами на HH- 
терфейсе 198.200.200.1, а экземпляр со стандартными сервисами — на всех осталь- 
ных интерфейсах, указав универсальный адрес INADDR ANY. Поскольку tcpmux 
устанавливает опцию So REUSEADDR, ТСР позволяет повторно привязать порт 1, 
хотя при второй привязке указан универсальный адрес. 

И, наконец, SO. REUSEADDR используется в системах с поддержкой группового 
вещания, чтобы дать возможность одновременно нескольким приложениям про- 
слушивать входящие датаграммы, вещаемые на группу. Подробнее это рассматри- 
вается в книге [Stevens 1998]. 


Резюме 


В этом разделе рассмотрена опция сокета SO. REUSEADDR. Ее установка позво- 
ляет перезапустить сервер, от предыдущего «воплощения» которого еще осталось 
соединение в состоянии TIME-WAIT. Серверы должны всегда устанавливать эту 
опцию, которая не влечет угрозу безопасности. 


Совет 24. По возможности пишите один большой 
блок вместо нескольких маленьких 


Для этой рекомендации есть несколько причин. Первая очевидна и уже обсуж- 
далась выше: каждое обращение к функциям записи (write, send и т.д.) требует, 
по меньшей мере, двух контекстных переключений, а это довольно дорогая опера- 
ция. С другой стороны, многократные операции записи (если не считать случаев 
типа записи по одному байту) не требуют заметных накладных расходов в прило- 
жении. Таким образом, совет избегать лишних системных вызовов — это, скорее, 
«правила хорошего тона», а не острая необходимость. 

Есть, однако, и более серьезная причина избегать многократной записи мел- 
ких блоков – эффект алгоритма Нейгла. Этот алгоритм кратко рассмотрен B сове- 
те 15. Теперь изучим его взаимодействие с приложениями более детально. Если не 
принимать в расчет алгоритм Нейгла, то это может привести к неправильному ре- 
шению задач, так или иначе связанных с ним, и существенному снижению произ- 
водительности некоторых приложений. 

К сожалению, алгоритм Нейгла, равно как и состояние TIME-WAIT, многие 
программисты понимают недостаточно хорошо. Далее будут рассмотрены причи- 
ны появления этого алгоритма, способы его отключения и предложены эффектив- 
ные решения, которые обеспечивают хорошую производительность приложению, 
не оказывая негативного влияния на сеть в целом. 

Алгоритм был впервые предложен в 1984 году Джоном Нейглом (КЕС 896 
[Nagle 1984]) для решения проблем производительности таких программ, как telnet 
и ей подобных. Обычно эти программы посылают каждое нажатие клавиши B OT- 
дельном сегменте, что приводит к засорению сети множеством крохотных дата- 
грамм (tinygrams). Если принять во внимание, что минимальный размер TCP-cer- 
мента (без данных) равен 40 байт, то накладные расходы при посылке одного 
байта в сегменте достигают 4000%. Но важнее то, что увеличивается число 
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пакетов в сети. А это приводит к перегрузке и необходимости повторной передачи, 
из-за чего перегрузка еще более увеличивается. В неблагоприятном случае в сети 
находится несколько копий каждого сегмента, и пропускная способность резко сни- 
жается по сравнению с номинальной. 

Соединение считается простаивающим, если в нем нет неподтвержденных дан- 
ных (то есть хост на другом конце подтвердил все отправленные ему данные). 
В первоначальном виде алгоритм Нейгла должен был предотвращать описанные 
выше проблемы. При этом новые данные от приложения не посылаются до тех пор, 
пока соединение не перейдет в состояние простоя. В результате в соединении не 
может находиться более одного небольшого неподтвержденного сегмента. 

Процедура, описанная в RFC 1122 [Braden 1989] несколько ослабляет это тре- 
бование, разрешая посылать данные, если их хватает для заполнения целого сег- 
мента. Иными словами, если можно послать не менее MSS байт, то это разрешено, 
даже если соединение не простаивает. Заметьте, что условие Нейгла при этом по- 
прежнему выполняется: в соединении находится не более одного небольшого не- 
подтвержденного сегмента. 

Многие реализации не следуют этому правилу буквально, применяя алгоритм 
Нейгла не к сегментам, а к операциям записи. Чтобы понять, в чем разница, пред- 
положим, что MSS составляет 1460 байт, приложение записывает 1600 байт, в ок- 
нах приема и передачи свободно, по меньшей мере, 2000 байт и соединение проста- 
ивает. Если применить алгоритм Нейгла к сегментам, то следует послать 1460 байт, 
а затем ждать подтверждения перед отправкой следующих 140 байт — алгоритм 
Нейгла применяется при посылке каждого сегмента. Если же использовать алго- 
ритм Нейгла к операциям записи, то следует послать 1460 байт, а вслед за ними 
еще 140 байт — алгоритм применяется только тогда, когда приложение передает 
ТСР новые данные для доставки. 

Алгоритм Нейгла работает хорошо и не дает приложениям забить сеть крохот- 
ными пакетами. В большинстве случае производительность не хуже, чем в реали- 
зации ТСР, в которой алгоритм Нейгла отсутствует. 


Примечание Представьте, например, приложение, которое передает ТСР 
один байт каждые 200 мс. Если период кругового обращения (RTT) 
для соединения равен одной секунде, то ТСР без алгоритма Ней- 
гла будет посылать пять сегментов в секунду с накладными 
расходами 4000%. При наличии этого алгоритма первый байт 
отсылается сразу, а следующие четыре байта, поступившие от 
приложения, будут задержаны, пока не придет подтверждение 
на первый сегмент. Тогда все четыре байта посылаются сразу. 
Таким образом, вместо пяти сегментов послано только два, за 
счет чего накладные расходы уменьшились до 1600% при сохра- 
нении той же скорости 5 байт/С. 


К сожалению, алгоритм Нейгла может плохо взаимодействовать с другой, до- 
бавленной позднее возможностью ТСР — отложенным подтверждением. 
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Когда прибывает сегмент от удаленного хоста, ТСР задерживает отправку 
АСК в надежде, что приложение скоро ответит на только что полученные данные. 
Поэтому АСК можно будет объединить с данными. Традиционно в системах, про- 
изводных от BSD, величина задержки составляет 200 мс. 


Прамечание В ВЕС 1122 не говорится о сроке задержки, требуется лишь, 
чтобы она была не больше 500 мс. Рекомендуется также под- 
тверждать, по крайней мере, каждый второй сегмент. 


Отложенное подтверждение служит той же цели, что и алгоритм Нейгла – 
уменьшить число повторно передаваемых сегментов. 

Принцип совместной работы этих механизмов рассмотрим на примере типич- 
ного сеанса «запрос/ответ». Как показано на рис. 3.12, клиент посылает короткий 
запрос серверу, ждет ответа и посылает следующий запрос. 

Заметьте, что алгоритм Нейгла не применяется, поскольку клиент не посыла- 
ет новый сегмент, не дождавшись ответа на предыдущий запрос, вместе с которым 
приходит и АСК. На стороне сервера задержка подтверждения дает серверу время 
ответить. Поэтому для каждой пары запрос/ответ нужно всего два сегмента. Если 
через КТТ обозначить период кругового обращения сегмента, а через Т, – время, 

необходимое серверу для обработки запроса и отправки ответа (в миллисекундах), 
TO на каждую пару запрос/ответ уйдет RTT + T, мс. 

А теперь предположим, что клиент посылает СВОЙ запрос в виде двух последова- 
тельных операций записи. Часто причина в том, что запрос состоит из заголовка, за 
которым следуют данные. Например, клиент, который посылает серверу запросы 
переменной длины, может сначала послать длину запроса, а потом сам запрос. 


Примечание Пример такого типа изображен на рис. 2.17, но там были приня- 
ты меры для отправки длины и данных в составе одного сегмента. 


На рис. 3.13 показан поток данных. 


Клиент Сервер 
Клиент Сервер 


Запрос (часть 1) 


200 мс 
Ответ + <А 200 мс 


) 200 Mc 


Рис. 3.12. Поток данных из одиночных Рис. 3.13. Взаимодействие алгоритма 
сегментов сеанса «запрос/ответ» Нейгла и отложенного подтверждения 


200 мс 
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На этот раз алгоритмы взаимодействуют так, что число сегментов, посланных 
на каждую пару запрос/ответ, удваивается, и это вносит заметную задержку. 

Данные из первой части запроса посылаются немедленно, но алгоритм Нейгла 
не дает послать вторую часть. Когда серверное приложение получает первую часть 
запроса, оно не может ответить, так как запрос целиком еще не пришел. Это зна- 
чит, что перед посылкой подтверждения на первую часть должен истечь тайм-аут 
установленный таймером отложенного подтверждения. Таким образом, алгорит- 
мы Нейгла и отложенного подтверждения блокируют друг друга: алгоритм Нейг- 
ла мешает отправке второй части запроса, пока не придет подтверждение на первую, 
аалгоритм отложенного подтверждения не дает послать АСК, пока не сработает тай- 
мер, поскольку сервер ждет вторую часть. Теперь для каждой пары запрос/ответ 
нужно четыре сегмента и 2 X КТТ +Т, + 200 мс. В результате за секунду можно 
обработать не более пяти пар запрос /ответ, даже если забыть о времени обработки 
запроса сервером и о периоде кругового обращения. 


Примечание Для многих систем это изложение чрезмерно упрощенное. На- 
пример, системы, производные om BSD, каждые 200 мс проверя- 
ют все соединения, для которых подтверждение было отложено. 
При этом АСК посылается независимо от того, сколько времени 
прошло в действительности. Это означает, что реальная задер- 
жка может составлять от 0 до 200 мс, в среднем 100 мс. Одна- 
ко часто задержка достигает 200 мс из-за «фазового эффекта», 
состоящего в том, что ожидание прерывается следующим так- 
том таймера через 200 мс. Первый же ответ синхронизирует 
ответы с тактовым генератором. Хороший пример такого по- 
ведения см. в работе [Minshall et al. 1999]. 


Последний пример показывает причину проблемы: клиент выполняет после- 
довательность операций «запись, запись, чтение». Любая такая последователь- 
ность приводит к нежелательной интерференции между алгоритмом Нейгла и алго- 
ритмом отложенного подтверждения, поэтому ее следует избегать. Иными словами, 
приложение, записывающее небольшие блоки, будет страдать всякий раз, когда 
хост на другом конце сразу не отвечает. 

Представьте приложение, которое занимается сбором данных и каждые 50 мс 
посылает серверу одно целое число. Если сервер не отвечает на эти сообщения, 
а просто записывает данные в журнал для последующего анализа, то будет наблю- 
даться такая же интерференция. Клиент, пославший одно целое, блокируется ал- 
горитмом Нейгла, а затем алгоритмом отложенного подтверждения, например на 
200 мс, после чего посылает по четыре целых каждые 200 мс. 


Отключение алгоритма Нейгла 


Поскольку сервер из последнего примера записывал в журнал полученные 
данные, взаимодействие алгоритмов Нейгла и отложенного подтверждение не 
принесло вреда и, по сути, уменьшило общее число пакетов в четыре раза. Допустим, 
что клиент посылает серверу серию результатов измерения температуры, и сервер 
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должен отреагировать в течение 100 мс, если показания выходят за пределы допу- 
стимого диапазона. В этом случае задержка на 200 мс, вызванная интерференци- 
ей алгоритмов, уже нетерпима, и ее надо устранить. 

Хорошо, что ВЕС 1122 требует наличия метода, отключающего алгоритм Нейг- 
ла. Пример с клиентом, следящим за температурой, — это один из случаев, когда 
такое отключение необходимо. Менее драматичный, но более реалистичный при- 
мер относится к системе X-Window, работающей на платформе UNIX. Поскольку 
Х использует протокол ТСР для общения между дисплеем (сервером) и приложе- 
нием (клиентом), Х-сервер должен доставлять информацию о действиях пользо- 
вателя (перемещении курсора мыши) Х-клиенту без задержек, вносимых алгорит- 
мом Нейгла. 

В API сокетов можно отключить алгоритм Нейгла с помощью установки оп- 
ции сокета ТСР NODELAY. 


const int оп = 1; 
Setsockopt( s, IPPROTO TCP, TCP NODELAY, &on, sizeof( on ) ); 


Но возможность отключения алгоритма Нейгла вовсе не означает, что это обя- 
зательно делать. Приложений, имеющих реальные основания отключать алго- 
ритм, значительно меньше, чем тех, которые это делают без причины. Причина, по 
которой программисты с пугающей регулярностью сталкиваются с классической 
проблемой интерференции между алгоритмами Нейгла и отложенного подтверж- 
дения, в том, что делают много мелких операций записи вместо одной большой. 
Потом они замечают, что производительность приложений намного хуже, чем ожи- 
далось, и спрашивают, что делать. И кто-нибудь обязательно ответит: «Это все 
алгоритм Нейгла. Отключите erol». Нет нужды говорить, что после отключения 
этого алгоритма проблема производительности действительно исчезает. Только за 
это приходится расплачиваться увеличением числа крохотных пакетов в сети. 
Если так работают многие приложения или, что еще хуже, алгоритм Нейгла от- 
ключен по умолчанию, то возрастет нагрузка сети. В худшем случае это может 
привести к полному затору. 


Запись со сбором 


Как видите, существуют приложения, которые, действительно, должны от- 
ключать алгоритм Нейгла, но в основном это делается из-за проблем с производи- 
тельностью, причина которых в отправке логически связанных данных серией из 
отдельных операций записи. Есть много способов собрать данные, чтобы послать 
их вместе. Наконец всегда можно скопировать различные порции данных в один 
буфер, которые потом и передать операции записи. Но, как объясняется в совете 
26, к такому методу следует прибегать в крайнем случае. Иногда можно организо- 
вать хранение данных в одном месте, как и сделано в листинге 2.15. Чаще, однако, 
данные находятся в нескольких несмежных буферах, а хотелось бы послать их 
одной операцией записи. 

Для этого и в UNIX, и в Winsock предусмотрен некоторый способ. К сожале- 
нию, эти способы немного отличаются. В UNIX есть системный вызов writev 
и парный ему вызов readv. При использовании writev вы задаете список буферов, 
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из которых должны собираться данные. Это решает исходную задачу: можно 
размещать данные в нескольких буферах, а записывать их одной операцией, 
исключив тем самым интерференцию между алгоритмами Нейгла и отложен- 
ного подтверждения. 

#1пс1аае «sys/uio.h» 


ssize t writev( int fd, const struct iovec *iov, int cnt ); 


ssize t readv( int fd, const struct iovec *iov, int cnt ); 


Возвращаемое значение: число переданных байт или —1 в случае ошибки. 


Параметр iov - это указатель на массив структур iovec, в которых хранятся 
указатели на буферы данных и размеры этих буферов: 


struct iovec { 
char *iov base; /* Адрес начала буфера. */ 
size t iov len; /* Длина буфера. */ 

}; 


Примечание Это определение взято из системы FreeBSD. Теперь во многих 
системах адрес начала буфера определяется так: 


void *iov base; /* адрес начала буфера */ 


Третий параметр, cnt — это число структур iovec в массиве (иными словами, 
количество буферов). 

У вызовов writev и readv практически общий интерфейс. Их можно исполь- 
зовать для любых файловых дескрипторов, а не только для сокетов. 

Чтобы это понять, следует переписать клиент (листинг 3.23), работающий 
с записями переменной длины (листинг 2.15), с использованием writev. 


Листинг 3.23. Клиент, посылающий записи переменной длины с помощью Writev 


vrcv.c 
І #include "etcp.h" 
2 finclude «sys/uio.h» 


3 int main( int argc, char **argv ) 


4 { 

5 SOCKET $; 

6 int n; 

7 char buf[ 128 ]; 

8 struct iovec iov[ 2 ]; 


9 INIT(); 

10 S = tcp client( argv[ 1 ], argv[i 2 ] ); 
11 iov[ 0 ].iov. base = ( char * )&n; 

12 iov[ 0 l.iov len = sizeof( n ); 

13 iov[ 1 ].іоу раѕе = buf; 


14 while ( fgets( buf, sizeof( buf ), stdin ) != NULL ) 
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15 { 
16 іоу[ 1 ].iov len = strlen( buf ); 
17 n = htonl( iov[ 1 ].iov len ); 
18 if ( writev( s, iov, 2 ) < 0) 
19 error( 1, errno, "ошибка вызова writev" ); 
20 ) 
21 EXIT( O ); 
22 } 
vrcv.c 
Инициализация 


9-13 Выполнив обычную инициализацию клиента, формируем массив 
iov. Поскольку в прототипе writev имеется спецификатор const для 
структур, на которые указывает параметр iov, то есть гарантия, что 
массив iov не будет изменен внутри writev, так что большую часть 
параметров можно задавать вне цикла while. 


Цикл обработки событий 


14-20 Вызываем fgets для чтения одной строки из стандартного ввода, вы- 
числяем ее длину и записываем в поле структуры из массива iov. Kpo- 
ме того, длина преобразуется в сетевой порядок байт и сохраняется 
в переменной п. 


Если запустить сервер vrs (совет 6) и вместе c ним клиента Vrcv, TO получат- 
ся те же результаты, что и раньше. 
В спецификации Winsock определен другой, хотя и похожий интерфейс. 


#include «winsock2.h» 


int WSAAPI WSAsend( SOCKET s, LPWSABUF, DWORD cnt, 
LPDWORD sent, DWORD flags, LPWSAOVERLAPPED ovl, 
LPWSAOVERLAPPED COMPLETION ROUTINE func ); 


Возвращаемое значение: 0 B случае успеха, в противном случае SOCKET. ERROR. 


Последние два аргумента используются при вводе/выводе с перекрытием, 
и в данном случае не имеют значения, так что обоим присваивается значение NULL. 
Параметр buf указывает на массив структур типа WSABUF, играющих ту же роль, 
что структуры iovec в вызове writev. 


typedef struct | WSABUF { 

u long len; /* Длина буфера. */ 

char FAR * buf; /* Указатель Ha начало буфера. */ 
) WSABUF, FAR * LPWSABUF; 


Нараметр sent - это указатель Ha переменную типа DWORD, в которой xpaHHT- 
ся число переданных байт при успешном завершении вызова. Параметр flags aHa- 
логичен одноименному параметру в вызове Send. 

Версия клиента, посылающего сообщения переменной длины, на платформе 
Windows выглядит так (листинг 3.24): 
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Листинг 3.24. Версия vrcv для Winsock 


VICVW.C 

1 #1пс1аае "etcp.h" 

2 int main( int argc, char **argv ) 

3 { 

4 SOCKET s; 

5 int n; 

6 char buf[ 128 ]; 

7 WSABUF wbuf([ 2 ]; 

8 DWORD sent; 

9 INIT(); 

10 S = tcp client( argv[ 1 ], argv[ 2 ] ); 

11 wbuf[ 0 J.buf = ( char * )&n; 

12 wbuf[( 0 ].1еп = sizeof( n ); 

13 wbuf[ 1 ].buf = buf; 
14 while ( fgets( buf, sizeof( buf ), stdin ) != NULL ) 

15 { 
16 wbuf[ 1 ].1еп = strlen( buf ); 
17 п = htonl( wbu£[ 1 ].1еп ); 
18 if ( WSASend( s, wbuf, 2, &sent, 0, NULL, NULL ) < 0 ) 
19 error( 1, errno, "ошибка вызова WSASend" ); 
20 ) 
21 EXIT( 0 ); 
22 } 
угсуи. с 


Как видите, если не считать иного обращения к вызову записи со сбором, то 
Winsock-Bepcus идентична ОМІХ-версии. 


Резюме 


В этом разделе разобран алгоритм Нейгла и его взаимодействие с алгоритмом 
отложенного подтверждения. Приложения, записывающие в сеть несколько малень- 
ких блоков вместо одного большого, могут заметно снизить производительность. 

Поскольку алгоритм Нейгла помогает предотвратить действительно серьезную 
проблему – переполнение сети крохотными пакетами, не следует отключать его для 
повышения производительности приложений, выполняющих запись мелкими блока- 
ми. Вместо этого следует переписать приложение так, чтобы все логические связан- 
ные данные выводились сразу. Здесь был рассмотрен удобный способ решения этой 
задачи с помощью системного вызова writev в UNIX или WSASend в Winsock. 


Совет 25. Научитесь организовывать тайм-аут 
для вызова connect 


В совете 7 отмечалось, что для установления ТСР-соединения стороны 
обычно должны обменяться тремя сегментами (это называется трехсторонним 
квитированием). Как показано на рис. 3.14, эта процедура инициируется вызовом 
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connect со стороны клиента и завершается, когда сервер получает подтвержде- 
ние АСК на посланный им сегмент SYN. 


Примечание Возможны, конечно, и другие варианты обмена сегментами. На- 
пример, одновременный connect, когда сегменты 5УМ переда- 
ются навстречу друг другу. Но в большинстве случаев соедине- 
ние устанавливается именно так, как показано на рис. 3.14. 


Клиент Сервер 


Вызван connect 
«SYN» 


RTT 


connect вернул 
управление 


Рис. 3.14 Обычная процедура 
трехстороннего квитирования 


При использовании блокирующего сокета вызов connect не возвращает 
управления, пока не придет подтверждение АСК на посланный клиентом SYN. По- 
скольку для этого требуется, по меньшей мере, время RTT, а при перегрузке сети 
или недоступности хоста на другом конце — даже больше, часто бывает полезно 
прервать вызов connect. Обычно ТСР делает это самостоятельно, но время ожи- 
дания (как правило, 75 с) может быть слишком велико для приложения. В некото- 
рых реализациях, например в системе Solaris, есть опции сокета для управления 
величиной тайм-аута connect, но, к сожалению, они имеются не во всех системах. 


Использование вызова alarm 


Есть два способа прерывания connect по тайм-ауту. Самый простой ~ окру- 
жить этот вызов обращениями к alarm. Предположим, например, что вы He хо- 
тите ждать завершения connect более пяти секунд. Тогда можно модифициро- 
вать каркас tcpclient.skel (листинг 2.6), добавив простой обработчик сигнала 
и немного видоизменив функцию main: 


void alarm hndlr( int sig ) 
( 


return; 


) 


int main( int argc, char **argv ) 


( 


signal( SIGALRM, alarm hndlr ); 
alarm( 5 ); 
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rc = connect( s, ( struct sockaddr * )&peer, sizeof( peer ) ); 
alarm( O ); 
if (rc <0) 
( 
if ( errno == EINTR ) 
error( 1, 0, "истек тайм-аут connect Mn" ); 


) 


Назовем программу, созданную по этому каркасу, connecto и попытаемся с ee 
помощью соединиться с очень загруженным Web-cepBepoM Yahoo. Получится 
ожидаемый результат: 

bsd: $ connectto yahoo.com daytime 


connectto: истек тайм-аут connect спустя 5 c 
bsd: $ 


Хотя это и простое решение, с ним связано две потенциальных проблемы. Сна- 
чала обсудим их, а потом рассмотрим другой метод — он сложнее, но лишен этих 
недостатков. 

Прежде всего в данном примере подразумевается, что «тревожный» таймер, ис- 
пользуемый в вызове alarm, нигде в программе не применяется, и, значит, для CHT- 
нала SIGALRM не установлен другой обработчик. Если таймер уже взведен где-то 
еще, то приведенный код его переустановит, поэтому старый таймер не сработает. 
Правильнее было бы сохранить и затем восстановить время, оставшееся до сраба- 
тывания текущего таймера (его возвращает вызов alarm), а также сохранить 
и восстановить текущий обработчик сигнала SIGALRM (его адрес возвращает вызов 
signal). Чтобы все было корректно, надо было также получить время, проведен- 
ное в вызове connect, и вычесть ero из времени, оставшегося до срабатывания 
исходного таймера. 

Далее, для упрощения вы завершаете клиент, если connect не вернул управ- 
ления вовремя. Вероятно, нужно было бы предпринять иные действия. Однако 
надо иметь в виду, что перезапустить connect нельзя. Дело B том, что в результате 
вызова connect сокет остался привязанным к ранее указанному адресу, так что 
попытка повторного выполнения приведет к ошибке «Address already in use». При 
желании повторить connect, возможно, немного подождав, придется сначала 3a- 
крыть, а затем заново открыть сокет, вызвав Close (или closesocket) и socket. 

Еще одна потенциальная проблема в том, что некоторые ОМІХ-системы MO- 
гут автоматически возобновлять вызов connect после возврата из обработчика 
сигнала. В таком случае connect не вернет управления, пока не истечет тайм-аут 
ТСР. Во всех современных вариантах системы UNIX поддерживается вызов 
sigaction, который можно использовать вместо signal. В таком случае следует 
указать, хотите ли вы рестартовать connect. Но в некоторых устаревших версиях 
UNIX этот вызов не поддерживается, и тогда использование alarm для прерыва- 
ния connect по тайм-ауту затруднительно. 

Если нужно вывести всего лишь диагностическое сообщение и завершить се- 
анс, то это можно сделать в обработчике сигнала. Поскольку это происходит до рес- 
тарта connect, не имеет значения, поддерживает система вызов sigaction или нет. 
Однако если нужно предпринять какие-то другие действия, то, вероятно, придется 


Организация тайм-аута для вызова connect Ш ШЕШЕ 


выйти из обработчика с помощью функции longjmp, а это неизбежно приводит 
к возникновению гонки. 


Примечание 


Следует заметить, что гонка возникает и в более простом слу- 
чае, когда вы завершаете программу. Предположим, что соеди- 
нение успешно установлено, и connect вернул управление. Od- 
нако прежде чем вы успели его отменить, таймер сработал, что 
привело к вызову обработчика сигнала и, следовательно, к завер- 
шению программы. 


alarm( 5 ); 
rc = connect( s, NULL, NULL ); 
/* здесь срабатывает таймер */ 
alarm ( O ); 


Вы завершаете программу, хотя соединение и удалось устано- 
вить. В первоначальном коде такая гонка не возникает, посколь- 
ку даже если таймер сработает между возвратом из connect 
и вызовом alarm, обработчик сигнала вернет управление, не 
предпринимая никаких действий. 


Принимая это во внимание, многие эксперты считают, что для прерывания 
вызова connect по тайм-ауту лучше использовать select. 


Использование select 


Другой, более общий метод организации тайм-аута connect состоит в TOM, 
чтобы сделать сокет неблокирующим, а затем ожидать с помощью вызова select. 
При таком подходе удается избежать большинства трудностей, возникающих при 
попытке воспользоваться alarm, но остаются проблемы переносимости даже меж- 
ду разными ОМІХ-системами. 

Сначала рассмотрим код установления соединения. В каркасе tcpclient.skel 
модифицируйте функцию main, как показано в листинге 3.25. 


Листинг 3.25. Прерывание connect по тайм-ауту с помощью select 


int main( 


1 

2 

3 fd set 
4 fd set 
5 fd set 
6 struct 
7 struct 
8 SOCKET 


connecttol.c 
int argc, char **argv ) 


rdevents; 
wrevents; 
exevents; 
Sockaddr in peer; 
timeval tv; 

S; 


9 int flags; 


10 int rc; 


11 INIT(); 


12 set address( argv[ 1 ] ; агау [ 2 1 Р &реег, "tep" ) ; 
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13 S = Socket( AF, INET, SOCK_STREAM, 0 ); 
14 if ( lisvalidsock( s ) ) 
15 error( 1, errno, "ошибка вызова socket " ); 
16 if( ( flags = fcntl( s, Е GETFL, 0 ) ) « 0 ) 
17 error( 1, errno, "ошибка вызова fcntl (Е СЕТЕ)" ); 
18 if ( fentl( s, Е SETFL, flags | O .NONBLOCK ) < O ) 
19 error( 1, errno, "ошибка вызова fcntl (F SETFL)" ); 
20 if ( (гс = connect( s, ( struct sockaddr * )&peer, 
21 sizeof( peer ) ) ) && errno != EINPROGRESS ) 
22 error( 1, errno, "ошибка вызова connect" ); 
23 if (rc == 0 ) /* Уже соединен? */ 
24 { 
25 if ( fcntl( s, ЕЁ SETFL, flags ) < 0) 
26 error( 1, errno, "ошибка вызова fcntl (восстановление флагов)" 
); 
27 client( s, &peer ); 
28 EXIT( 0 ); 
29 ) 
30 FD. ZERO( &rdevents ); 
31 FD SET( s, &rdevents ); 
32 wrevents = rdevents; 
33 exevents - rdevents; 
34 tv.tv sec = 5; 
35 tv.tv usec = 0; 
36 rc = select( S + 1, &rdevents, &wrevents, &exevents, &tVv ); 
37 if ( re « D) 
38 error( 1, errno, "ошибка вызова select" ); 
39 else if ( rc == ) 
40 error( 1, 0, "истек тайм-аут соппесе\п" ); 
41 else if ( isconnected( s, &rdevents, &wrevents, &exevents ) ) 
42 ( 
43 if ( fcntl( s, Е SETFL, flags ) < 0 ) 
44 error( 1, errno, "ошибка вызова fcntl (восстановление флагов)" 
hi 
45 client( s, &peer ); 
46 ) 
47 else 
48 error( 1, errno, "ошибка вызова connect" ); 
49 EXIT( O ); 
50 } 
connecttoí.c 
Инициализация 


16-19 Получаем текущие флаги, установленные для сокета, с помощью опе- 


рации OR, добавляем к ним флаг О_МОМВГОСК и устанавливаем новые 
флаги. 


Инициирование connect 
20-29 Начинаем установление соединения с помощью вызова connect. По- 


скольку сокет помечен как неблокирующий, connect немедленно 


Организация тайм-аута для вызова connect {1 ИХ] 


возвращает управление. Если соединение уже установлено (это воз- 
можно, если, например, вы соединялись с той машиной, на которой за- 
пущена программа), то connect вернет нуль, поэтому возвращаем сокет 
в режим блокирования и вызываем функцию client. Обычно в момент 
возврата H3 connect соединение еще не установлено, и приходит код 
EINPROGRESS. Если возвращается другой код, то печатаем диагности- 
ческое сообщение и завершаем программу. 


Вызов select 


30-36 Подготавливаем, как обычно, данные для select и, в частности, ycTa- 
навливаем тайм-аут на пять секунд. Также следует объявить заинтере- 
сованность в событиях исключения. Зачем — станет ясно позже. 


Обработка код возврата select 


37-40 Если select возвращает код ошибки или признак завершения по тайм- 
ауту, то выводим сообщение и заканчиваем работу. В случае ответа 
можно было бы, конечно, сделать что-то другое. 

41-46 Вызываем функцию isconnected, чтобы проверить, удалось ли уста- 
новить соединение. Если да, возвращаем сокет в режим блокирования 
и вызываем функцию client. Текст функции isconnected приведен 
в листингах 3.26 и 3.27. 

47-48 Если соединение не установлено, выводим сообщение и завершаем сеанс. 


К сожалению, B UNIX и в Windows применяются разные методы уведомления 
об успешной попытке соединения. Поэтому проверка вынесена в отдельную функ- 
цию. Сначала приводится UNIX-Bepcus функции isconnected. 

B UNIX, если соединение установлено, сокет доступен для записи. Если же 
произошла ошибка, то сокет будет доступен одновременно для записи и для чте- 
ния. Однако на это нельзя полагаться при проверке успешности соединения, по- 
скольку можно возвратиться H3 Connect и получить первые данные еще до обра- 
щения к select. В таком случае сокет будет доступен и для чтения, и для записи — 
в точности, как при возникновении ошибки. 


Листинг 3.26. ОМІХ-версия функции isconnected 


connecttoi.c 


1 int isconnected( SOCKET s, fd set *rd, fd set *wr, fd set *ех ) 
2 t 

3 int err; 

4 int len = sizeof( err ); 

5 еггпо = 0; /* Предполагаем, что ошибки нет. */ 

6 if ( !FD ISSET( s, rd ) && !FD ISSET( s, wr ) ) 

7 return 0; 

8 if ( getsockopt( s, SOL SOCKET, SO ERROR, &err, &len ) < 0) 
9 return 0; 
10 errno = err; /* Если MH He соединились. */ 
11 return err -- 0; 

12 ) 


connecttoi.c 
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5-7 Если сокет не доступен HH для чтения, HH для записи, значит, соединение 
не установлено, и возвращается нуль. Значение еггпо заранее установ- 
лено в нуль, чтобы вызывающая программа могла определить, что сокет, 
действительно, не готов (разбираемый случай) или имеет место ошибка. 

8-11 Вызываем get sockopt для получения статуса сокета. В некоторых Bep- 
сиях UNIX getsockopt возвращает в случае ошибки -1. В таком случае 
записываем B errno код ошибки. В других версиях система просто воз- 
вращает статус, оставляя его проверку пользователю. Идея кода, ко- 


торый корректно работает в обоих случаях, позаимствована из книги 
[Stevens 1998]. 


Согласно спецификации Winsock, ошибки, которые возвращает connect че- 
рез неблокирующий сокет, индицируются путем возбуждения события исключе- 
НИЯ B select. Следует заметить, что в UNIX событие исключения всегда свиде- 
тельствует о поступлении срочных данных. Версия функции isconnected для 
Windows показана в листинге 3.27. 


Листинг 3.27. ИИпаомз-версия функции isconnected 


connecttoil.c 


1 int isconnected( SOCKET s, fd set *rd, fd set *wr, fd set *ex ) 
2 { 

3 WSASetLastError( 0 ); 

4 if ( IFD ISSET( s, rd ) && !FD ISSET( s, wr ) ) 

5 return 0; 

6 if ( FD ISSET( S, ex ) ) 

7 return 0; 

8 return 1; 

9 ) 


connecttol.c 


3-5 Так же, как и B версии для UNIX, проверяем, соединен ли сокет. Если 
нет, устанавливаем последнюю ошибку в нуль и возвращаем нуль. 

6-8 Если для сокета есть событие исключения, возвращается нуль, в про- 
тивном случае – единица. 


Резюме 


Как видите, для переноса на разные платформы прерывать вызов connect 
с помощью тайм-аута более сложно, чем обычно. Поэтому при выполнении такого 
действия надо уделить особое внимание платформе. 

Наконец, следует понимать, что сократить время ожидания connect можно, 
а увеличить — нет. Все вышерассмотренные методы направлены на то, чтобы пре- 
рвать вызов connect раньше, чем это сделает ТСР. Не существует переносимого 
механизма для изменения значения тайм-аута ТСР на уровне одного сокета. 


Совет 26. Избегайте копирования данных 


Во многих сетевых приложениях, занимающихся, прежде всего, переносом дан- 
ных между машинами, болыная часть времени процессора уходит на копирование 
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данных из одного буфера в другой. В этом разделе будет рассмотрено несколько 
способов уменьшения объема копирования, что позволит «бесплатно» повысить 
производительность приложения. Предложение избегать копирования больших 
объемов данных в памяти оказывается не таким революционным, поскольку имен- 
но так всегда и происходит. Массивы передаются не целиком, используются толь- 
ко указатели на них. 

Конечно, обычно данные между функциями, работающими внутри одного про- 
цесса, не копируются. Но в многопроцессных приложениях часто приходится пе- 
редавать большие объемы данных от одного процесса другому с помощью того или 
иного механизма межпроцессного взаимодействия. И даже в рамках одного про- 
цесса часто доводится заниматься копированием, если сообщение состоит более 
чем из двух частей, которые нужно объединить перед отправкой другому процессу 
или другой машине, Типичный пример такого рода, обсуждавшийся в совете 24, — 
это добавление заголовка в начало сообщения. Сначала копируется в буфер заго- 
JIOBOK, а вслед за НИМ — само сообщение. 

Стремление избегать копирования данных внутри одного процесса — признак 
хорошего стиля программирования. Если заранее известно, что сообщению будет 
предшествовать заголовок, то надо оставить для него место в буфере. Иными сло- 
вами, если ожидается заголовок, описываемый структурой struct hdr, то прочи- 
тать данные можно было бы так: 


rc = read( fd, buf + sizeof( struct hdr ) ), 
sizeof( buf ) - sizeof( struct hdr ); 


Пример применения такой техники содержится B листинге 3.6. 

Еще один прием - определить пакет сообщения в виде структуры, одним из 
элементов которой является заголовок. Тогда можно просто прочитать заголовок 
в одном из полей: 


struct { 
struct hdr header; /* Структура определена в другом месте. */ 
char data[ DATASZ ]; 

) packet; 

rc = read( fd, packet, data. sizeof( packet data ) ); 


Пример использования этого способа был продемонстрирован в листинге 2.15. 
Там же говорилось, что при определении такой структуры следует проявлять 
осмотрительность. 

Третий, очень гибкий, прием заключается в применении операции записи CO 
сбором — листинги 3.23 (UNIX) и 3.24 (Winsock). Он позволяет объединять части 
сообщения с различными размерами. 

Избежать копирования данных намного труднее, когда есть несколько процессов. 
Эта проблема часто возникает в системе UNIX, где многопроцессные приложения — 
распространенная парадигма (рис. 3.4). Обычно в этой ситуации проблема даже ост- 
рее, так как механизмы ГРС, как правило, копируют данные отправляющего процесса 
в пространство ядра, а затем из ядра в пространство принимающего процесса, то есть 
копирование происходит дважды. Поэтому необходимо применять хотя бы один из 
вышеупомянутых методов, чтобы избежать лишних операций копирования. 
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Буферы в разделяемой памяти 


Обойтись почти без копирования, даже между разными процессами, можно, вос- 
пользовавшись разделяемой памятью. Разделяемая память — это область памяти, до- 
ступная сразу нескольким процессам. Каждый процесс отображает блок виртуальной 
памяти на адрес в собственном адресном пространстве (в разных процессах эти адреса 
могут быть различны), а затем обращается к нему, как к собственной памяти. 

Идея состоит в том, чтобы создать массив буферов в разделяемой памяти, 
построить сообщение в одном из них, а затем передать индекс буфера следующе- 
му процессу, применяя механизм IPC. При этом «перемещается» только одно це- 
лое число, представляющее индекс буфера в массиве. Например, на рис. 3.15 в ка- 
честве механизма IPC используется ТСР для передачи числа 3 от процесса 1 
процессу 2. Когда процесс 2 получает это число, он определяет, что приготовлены 
данные в буфере smbarray [3 ]. 


Процесс 1 


Формирование 
сообщения 


smbarray[3) 


ЕЕ rna и Получение 
сообщения 


ТСР-соединение 


Рис. 3.15. Передача сообщений через буфер в разделяемой памяти 


На рис. 3.15 два пунктирных прямоугольника представляют адресные простран- 
ства процессов 1 и 2, а их пересечение — общий сегмент разделяемой памяти, кото- 
рый каждый из процессов отобразил на собственное адресное пространство. Массив 
буферов находится в разделяемом сегменте и доступен обоим процессам. Процесс 1 
использует отдельный канал IPC (в данном случае — ТСР) для информирования про- 
цесса 2 о том, что для него готовы данные, а также место, где их искать. 

Хотя здесь показано только два процесса, этот прием прекрасно работает для 
любого их количества. Кроме того, процесс 2, в свою очередь, может передать CO- 
общение процессу 1, получив буфер в разделяемой памяти, построив в нем сооб- 
щение и послав процессу 1 индекс буфера в массиве. 
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Единственное, что пока отсутствует, — это синхронизация доступа к буферам, 
то есть предотвращение ситуации, когда два процесса одновременно получат один 
и тот же буфер. Это легко делается с помощью мьютекса, что и будет продемонст- 
рировано ниже. 


Система буферов в разделяемой памяти 


Описанную систему буферов в разделяемой памяти легко реализовать. Основ- 
ная сложность в том, как получить область разделяемой памяти, отобразить ее на 
собственное адресное пространство и синхронизировать доступ к буферам. Конеч- 
но, это зависит от конкретной системы, поэтому далее будет приведена реализа- 
ция как для UNIX, так и для Windows. 

Но прежде чем перейти к системно-зависимым частям, обратимся к API и ero 
реализации. На пользовательском уровне система состоит из пяти функций: 


и c riu а M USO TETUR UIN SIEUT uve X LLL 


diinclude "etcp.nh" 

void init, smb( int init freelist); 

void *smballoc( void ); 

Возвращаемое значение: указатель на буфер в разделяемой памяти. 
void smbfree( void *smbptr ); 

void smbsend( SOCKET s, void * smbptr ); 

void *smbrecv( SOCKET s ); 


Возвращаемое значение: указатель Ha буфер в разделяемой памяти. 


ыыы ты ыыы — — — == 1] 


Перед тем как пользоваться системой, каждый процесс должен вызвать 
функцию init, smb для получения и инициализации области разделяемой па- 
мяти и синхронизирующего мьютекса. При этом только один процесс должен 
вызвать init smb с параметром init freelist, равным TRUE. 

Для получения буфера в разделяемой памяти служит функция smballoc,B03- 
вращающая указатель на только что выделенный буфер. Когда буфер уже не ну- 
жен, процесс может вернуть его системе с помощью функции smb. free. 

Построив сообщение в буфере разделяемой памяти, процесс может передать 
буфер другому процессу, вызвав smbsend. Как уже говорилось, при этом передается 
только индекс буфера в массиве. Для получения буфера от отправителя процесс- 
получатель вызывает функцию smbrecv, которая возвращает указатель на буфер. 

В данной системе для передачи индексов буферов используется ТСР в каче- 
стве механизма IPC, но это не единственное и даже не оптимальное решение. Так 
удобнее, поскольку этот механизм работает как под UNIX, так и под Windows, 
иктому же можно воспользоваться уже имеющимися средствами, а не изучать дру- 
гие методы IPC. В системе UNIX можно было бы применить также сокеты B адрес- 
ном домене UNIX или именованные каналы. B Windows доступны SendMessage, 
QueueUserAPC и именованные каналы. 

Начнем рассмотрение реализации с функций smballoc и smbfree (листинг 3.28). 
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Листинг 3.28. Функции smballoc и smbfree 


smb.c 


1 £&include "etcp.h" 
2 #define FREE LIST smbarray[ NSMB ].nexti 
3 typedef union 
4 ( 
5 int nexti; 
6 char buf[ SMBUFSZ ]; 
7 } smb t; 
8 smb t *smbarray; 
9 void *smballoc( void ) 
10 ( 
11 smb t *bp; 
12 lock buf(); 
13 if ( FREE LIST < O0 ) 
14 error( 1, 0, "больше нет буферов B разделяемой памяти\п" ); 
15 bp = smbarray + FREE LIST; 
16 FREE LIST = bp-»nexti; 
17 unlock buf(); 
18 return bp; 
190 
20 void smbfree( void *b ) 
ZEE! 
22 smb t *bp; 
23 bp = b; 
24 lock buf(); 
25 bp-»nexti = FREE LIST; 
26 FREE LIST = bp - smbarray; 
27 unlock buf(); 
28 ) 
smb.c 
Заголовок 
2-8 Доступные буфера хранятся в списке свободных. При этом в первых 


sizeof( int ) байтах буфера хранится индекс следующего свободно- 
го буфера. Такая организация памяти отражена в объединении ѕтЫ t. 
В конце массива буферов есть одно целое число, которое содержит либо 
индекс первого буфера в списке свободных, либо —1, если этот список 
пуст. Доступ к этому числу вы получаете, адресуя его как smbarray 
[ NSMB ].nexti. Для удобства это выражение инкапсулировано в MaK- 
poc FREE_LIST. Насам массив буферов указывает переменная smbarray. 
Это, по сути, указатель на область разделяемой памяти, которую каж- 
дый процесс отображает на свое адресное пространство. В массиве ис- 
пользованы индексы, а не адреса элементов, так как в разных процес- 
сах эти адреса могут быть различны. 
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12 Вызываем функцию lock, buf, чтобы другой процесс не Mor обратить- 
ся к списку свободных. Реализация этой функции зависит от системы. 
B UNIX будут использованы семафоры, а B Windows — мьютексы. 

13-16 Получаем буфер из списка свободных. Если больше буферов нет, то 
выводим диагностическое сообщение и завершаем сеанс. Вместо этого 
можно было бы вернуть NULL. 

17-18 Открываем доступ к списку свободных и возвращаем указатель на 
буфер. 

smbfree 


23-27 После блокировки списка свободных, возвращаем буфер, помещая ero 
индекс в начало списка. Затем разблокируем список свободных и воз- 
вращаем управление. 


Далее рассмотрим функции smbsend и smbrecv (листинг 3.29). Они посыла- 
ют и принимают целочисленный индекс буфера, которым обмениваются процес- 
сы. Эти функции несложно адаптировать под иной механизм межпроцессного вза- 
имодействия. 


Листинг 3.29. Функции smbsend и smbrecv 


smb.c 

1 void smbsend( SOCKET s, void *b ) 

2 1 

3 int index; 

4 index - ( smb t * )b - smbarray; 

5 if ( send( s, ( char * )&index, sizeof( index ), 0 ) < 0) 
6 error( 1, errno, "smbsend: ошибка вызова send" ); 

7 ) 

8 void *smbrecv( SOCKET s ) 

9 { 

10 int index; 

11 int rc; 

12 гс = readn( s, ( char * )&index, sizeof( index ) ); 

13 if ( rc == 0) 

14 error( 1, 0, "smbrecv: другой конец отсоединился\п" ); 
15 else if ( rc != sizeof( index ) ) 

16 error( 1, errno, "smbrecv: ошибка вызова readn" ); 

17 return smbarray + index; 

18 } 

smb.c 

smbsend 
4-6 Вычисляем индекс буфера, на который указывает b, и посылаем его 


другому процессу с помощью send. 
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smbrecv 


12-16 Вызываем readn для чтения переданного индекса буфера. B случае 
ошибки чтения или при получении неожиданного числа байт, выводим 
сообщение и завершаем работу. 

17 В противном случае преобразуем индекс буфера в указатель на него 
и возвращаем этот указатель вызывающей программе. 


Реализация B UNIX 


Для завершения реализации системы буферов в разделяемой памяти нужны 
еще два компонента. Это способ выделения блока разделяемой памяти и отобра- 
жения его на адресное пространство процесса, а также механизм синхронизации 
для предотвращения одновременного доступа к списку свободных. Для работы 
с разделяемой памятью следует воспользоваться механизмом, разработанным в 
свое время для версии SysV. Можно было бы вместо него применить отображенный 
на память файл, как в Windows. Кроме того, есть еще разделяемая память B стан- 
дарте POSIX - для систем, которые ее поддерживают. 

Для работы с разделяемой памятью SysV понадобятся только два системных 
вызова : 


#include «sys/shm.h» 


int shmget( key t key, size t size, int flags ); 


Возвращаемое значение: идентификатор сегмента разделяемой памяти B слу- 
чае успеха, —1 — в случае ошибки. 


void shmat( int segid, const void *baseaddr, int flags ); 


Возвращаемое значение: базовый адрес сегмента в случае успеха, —1 — B слу- 
чае ошибки. 


Системный вызов shmget применяется для выделения сегмента разделяемой 
памяти. Первый параметр, key, — это глобальный для всей системы уникальный 
идентификатор, сегмента. Сегмент будет идентифицироваться целым числом, пред- 
ставление которого в коде ASCII равно SMBM. 


Примечание Использование пространства имен, отличного от файловой си- 
стемы, считается одним из основных недостатков механизмов 
IPC, появившихся еще в системе SysV. Для отображения имени 
файла на ключ IPC можно применить функцию ftok, но это 
отображение не будет уникальным. Кроме того, как отмечает- 
ся в книге [Stevens 1999], описанная в стандарте SVR4 функция 
£tok дает коллизию (то есть два имени файла отображаются 
на один и тот же ключ) с вероятностью 72%. 


Параметр size задает размер сегмента в байтах. Во многих ОМІХ-системах 
его значение округляется до величины, кратной размеру страницы. Параметр 
flags задает права доступа и другие атрибуты сегмента. Значения SHM R и SHM_W 
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определяют соответственно права на чтение и на запись для владельца. Права для 
группы и для всех получают путем сдвига этих значений вправо на три (для груп- 
пы) или шесть (для всех) бит. Иными словами, право на запись для группы — это 
SHM, W >> 3, а право на чтение для всех — SHM R >> 6. Когда в параметр flags 
с помощью побитовой операции ОК включается флаг ТРС_СВЕАТЕ, создается сег- 
мент, если раньше его не было. При дополнительном включении флага ТРС_ЕХСЬ 
shmget вернет код ошибки EEXIST, если сегмент уже существует. 

Вызов shmget только создает сегмент в разделяемой памяти. Для отображения 
его в адресное пространство процесса нужно вызвать shmat. Параметр segid – это 
идентификатор сегмента, который вернул вызов shmget. При желании можно ука- 
зать адрес baseaddr, на который ядро должно отобразить сегмент, но обычно этот 
параметр оставляют равным NULL, позволяя ядру самостоятельно выбрать адрес. 
Параметр flags используется, если значение baseaddr не равно NULL, — он управ- 
ляет выравниваем заданного адреса на приемлемую для ядра границу. 

Для построения механизма взаимного исключения следует воспользоваться 
ЗузУ-семафорами. Хотя они небезупречны (в частности, им присуща та же про- 
блема нового пространства имен, что и разделяемой памяти), SysV -ceMadcpopbr ши- 
poko используются в современных ОМХ-системах и, следовательно, обеспечивают 
максимальную переносимость. Как и в случае разделяемой памяти, сначала надо по- 
лучить и инициализировать семафор, а потом уже его применять. В данной ситу- 
ации понадобятся три относящихся к семафорам системных вызова. 

Вызов semget аналогичен shmget: он получает у операционной системы 
семафор и возвращает его идентификатор. Параметр key имеет тот же смысл, 
что и для shmget — он именует семафор. В ЗузУ-семафоры выделяются группами, 
и параметр nsems означает, сколько семафоров должно быть в запрашиваемой 
группе. Параметр flags такой же, как для shmget. 


&include «sys/sem.h» 


int semget( key t key, int nsems, int flags ); 


Возвращаемое значение: идентификатор семафора B случае успеха, —1 — в слу- 
чае ошибки. 


int semctl( int semid, int semnum, int cmd, ... ); 


Возвращаемое значение: неотрицательное число B случае успеха, —1 — B слу- 
чае ошибки. 


int semop( int semid, struct sembuf *oparray, size t nops ); 


Возвращаемое значение: 0 в случае успеха, —1 — в случае ошибки. 


Здесь использована semct1 для задания начального значения семафора. Этот 
вызов служит также для установки и получения различных управляющих пара- 
метров, связанных с семафором. Параметр semid - это идентификатор семафора, 
возвращенный вызовом semget. Параметр semnum означает конкретный семафор 
из группы. Поскольку будет выделяться только один семафор, значение этого па- 
раметра всегда равно нулю. Параметр cmd — это код выполняемой операции. 
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У вызова semget могут быть и дополнительные параметры, о чем свидетельству- 
ет многоточие в прототипе. 

Вызов зетор используется для увеличения или уменьшения значения сема- 
фора. Когда процесс пытается уменьшить семафор до отрицательного значения, 
он переводится в состояние ожидания, пока другой процесс не увеличит семафор 
до значения, большего или равного тому, на которое первый процесс пытался его 
уменьшить. Поскольку надо использовать семафоры в качестве мьютексов, сле- 
дует уменьшать значение на единицу для блокировки списка свободных и увели- 
чивать на единицу — для разблокировки. Так как начальное значение семафора 
равно единице, в результате процесс, пытающийся заблокировать уже блокирован- 
ный список свободных, будет приостановлен. 

Параметр semid – это идентификатор семафора, возвращенный semget. Па- 
раметр ораггау указывает на массив структур sembuf, в котором заданы опера- 
ции над одним или несколькими семафорами из группы. Параметр порз задает 
число элементов в массиве ораггау. 

Показанная ниже структура sembuf содержит информацию о том, к какому 
семафору применить операцию (sem num), увеличить или уменьшить значение 
семафора (sem op), а также флаг для двух специальных действий (sem. £19): 


struct sembuf { 


u short sem num; /* Номер семафора. */ 
short sem op; /* Операция над семафором. */ 
short sem flg; /* Флаги операций. */ 


IS 


В поле sem, f 1g могут быть подняты два бита флагов: 


О IPC, NOWAIT - означает, что semop должна вернуть код EAGAIN, a He приоста- 
навливать процесс, если в результате операции значение семафора окажется 
отрицательным; 

О SEM UNDO - означает, что semop должна отменить действие всех операций над 
семафором, если процесс завершается, то есть мьютекс будет освобожден. 


Теперь рассмотрим ОМХ-зависимую часть кода системы буферов в разделяе- 
мой памяти (листинг 3.30). 


Листинг 3.30. Функция init smb для UNIX 


smb.c 


finclude «sys/shm.h» 

finclude «sys/sem.h» 

fdefine MUTEX KEY 0x534d4253 /* SMBS */ 

fdefine SM KEY 0х534а424а /* SMBM */ 

fdefine lock риё () if ( semop( mutex, &lkbuf, 1 ) < O0) \ 
error( 1, errno, "ошибка вызова semop" ) 

fdefine unlock buf() if ( semop( mutex, &unlkbuf, 1 ) < 0) \ 
error( 1, errno, "ошибка вызова Semop" ) 


оомо Ui d» CO PO н 


int mutex; 
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10 struct sembuf lkbuf; 
11 struct sembuf unlkbuf; 


12 void init smb( int init freelist ) 


13 { 

14 union semun arg; 
15 int smid; 

16 int i; 

17 int rc; 


18 lkbuf.sem op = -1; 

19 lkbuf.sem flg = SEM UNDO; 

20 unlkbuf.sem op = 1; 

21 unlkbuf.sem flg = SEM UNDO; 
22 mutex = semget( MUTEX KEY, 1, 


23 IPC EXCL | IPC CREAT | SEM. В | SEM A ); 

24 if ( mutex >= 0) 

25 ( 

26 arg.val = 1; 

27 rc = semctl( mutex, 0, SETVAL, arg ); 

28 if (rc < 0) 

29 error( 1, errno, "semctl failed" ); 

30 ) 

31 else if ( errno == EEXIST } 

32 { 

33 mutex = semget( MUTEX KEY, 1, SEM_R | SEMA ); 
34 if ( mutex < 0 ) 

35 error( 1, errno, "ошибка вызова semctl" ); 
36 ) 

37 else 

38 error( 1, errno, "ошибка вызова Semctl" ); 


39 smid = shmget( SM KEY, NSMB * sizeof( smb t ) + sizeof( int ), 


40 SHM R | SHM_W | IPC CREAT ); 

41 if ( smid < O ) 

42 error( 1, errno, "ошибка вызова shmget" ); 
43 smbarray = ( smb t * )shmat( smid, NULL, 0 ); 
44 if ( smbarray -- ( void * )-1 ) 

45 error( 1, errno, "ошибка вызова shmat" ); 
46 if ( init, freelist ) 

47 { 

48 for (і = 0; і < NSMB- 1; i++ ) 

49 smbarray[ і ].nexti = i + 1; 

50 smbarray[ NSMB - 1 ].nexti = -1; 

51 FREE. LIST = 0; 

52 ) 

53 } 


smb.c 
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Макросы и г. лобальные переменные 


3-4 
5-8 


9-11 


Определяем ключи сегмента разделяемой памяти (SMBM) и семафо- 
pa (SMBS). 

Определяем примитивы блокировки и разблокировки B терминах опе- 
раций над семафорами. 

Объявляем переменные для семафоров, используемых для реализации 
мьютекса. 


Получение и инициализация семафора 


18-21 


22-38 


Инициализируем операции над семафорами, которыми будем пользо- 
ваться для блокировки и разблокировки списка свободных. 

Этот код создает и инициализирует семафор. Вызываем semget c фла- 
гами IPC EXCL и IPC, CREAT. В результате семафор будет создан, если 
он еще не существует, и в этом случае semget вернет идентификатор 
семафора, который инициализируем единицей (разблокированное со- 
стояние). Если же семафор уже есть, то снова вызываем semget, уже 
не задавая флагов IPC, EXCL и IPC, CREAT, для получения идентифи- 
катора этого семафора. Как отмечено в книге [Stevens 1999], теорети- 
чески здесь возможна гонка, но не в данном случае, поскольку сервер 
вызывает init, smb перед вызовом listen, а клиент не сможет обра- 
титься к нему, пока вызов connect не вернет управление. 


Примечание В книге [Stevens 1999] рассматриваются условия, при которых 


возможна гонка, и показывается, как ее избежать. 


Получение, отображение и инициализация буферов в разделяемой памяти 
39-45 Выделяем сегмент разделяемой памяти и отображаем его на свое ад- 


46-53 


ресное пространство. Если сегмент уже существует, то shmget возвра- 
щает его идентификатор. 

Если init smb была вызвана с параметром init freelist, равным 
ТВОЕ, то помещаем все выделенные буферы в список свободных и воз- 
вращаем управление. 


Реализация B Windows 


Прежде чем демонстрировать систему B действии, рассмотрим реализацию 
для Windows. Как было упомянуто выше, весь системно-зависимый код сосредо- 
точен в функции init, smb. B Windows мьютекс создается очень просто — доста- 
точно вызвать функцию CreateMutex. 


#1пс1аае «windows.h» 


HANDLE CreateMutex( LPSECURITY ATTRIBUTES lpsa, 


BOOL fInitialOwner, LPTSTR lpszMutexName ); 


Возвращаемое значение: описание мьютекса в случае успеха, NULL — в случае 
ошибки. 
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Параметр 1psa - это указатель на структуру с атрибутами защиты. Здесь эта 
возможность не нужна, так что вместо этого аргумента передадим NULL. Параметр 
flnitialOwner означает, будет ли создатель мьютекса его начальным владель- 
цем, то есть следует ли сразу заблокировать мьютекс. Параметр 1pszMutexName — 
это имя мьютекса, по которому к нему могут обратиться другие процессы. Если 
мьютекс уже существует, TO CreateMutex просто вернет его описание. 

Блокировка и разблокировка мьютекса выполняются соответственно с помо- 
щью функций WaitForSingleObject и ReleaseMutex. 


Kinclude «windows.h» 


DWORD WaitForSingleObject( HANDLE hObject, DWORD dwTimeout ); 


Возвращаемое значение: WAIT OBJECT, 0 (0) B случае успеха, ненулевое 3Ha- 
чение — в случае ошибки. 


BOOL ReleaseMutex( HANDLE hMutex ); 


Возвращаемое значение: TRUE B случае успеха, FALSE - B случае ошибки. 


Параметр hObject функции WaitForSingleObject - это описание ожидаемо- 
го объекта (в данном случае мьютекса). Если объект, заданный с помощью hObject, 
He занят (signaled), то WaitForSingleObject занимает ero и возвращает управ- 
ление. Если же объект занят (not signaled), то обратившийся поток переводит- 
ся в состояние ожидания до тех пор, пока объект не освободится. После этого 
WaitForSingleObject переведет объект в занятое состояние и вернет в работу 
«спящий» поток. Параметр dwTimeout задает время (B миллисекундах), в течение 
которого потоком ожидается освобождение объекта. Если тайм-аут истечет прежде, 
чем объект освободится, то WaitForSingleObject вернет код WAIT TIMEOUT. Тай- 
мер можно подавить, задав в качестве dwTimeout значение INFINITE. 

Когда поток заканчивает работу с критической областью, охраняемой мьютек- 
COM, он разблокирует его вызовом ReleaseMutex, передавая описание мьютекса 
hMutex в качестве параметра. 

В Windows вы получаете сегмент разделяемой памяти, отображая файл на па- 
мять каждого процесса, которому нужен доступ к разделяемой памяти (в UNIX 
есть аналогичный системный вызов mmap). Для этого сначала создается обычный 
файл с помощью функции CreateFile,asareM — отображение файла посредством 
вызова CreateFileMapping, а уже потом оно отображается на ваше адресное Ipo- 
странство вызовом MapViewOfFile. 

Параметр hFile в вызове CreateFileMapping - это описание отображаемого 
файла. Параметр 1psa указывает на структуру с атрибутами безопасности, которые 
B данном случае не нужны. Параметр £dwProtect определяет права доступа к объек- 
ту в памяти. Он может принимать значения PAGE READONLY, PAGE. READWRITE или 
PAGE WRITECOPY. Последнее значение заставляет ядро сделать отдельную копию 
данных, если процесс пытается записывать в страницу памяти. Здесь используется 
PAGE READWRITE, так как будет производится и чтение, и запись в разделяемую 
память. Существуют также дополнительные флаги, объединяемые операцией 
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побитового ОК, которые служат для управления кэшированием страниц памяти, 
но они не понадобятся. Параметры dwMaximumSizeHighMW dwMaximumSizeLowB co- 
вокупности дают 64-разрядный размер объекта в памяти. Параметр 1pszMapName - 
это имя объекта. Под данным именем объект известен другим процессам. 


#1пс1аае «windows.h» 


HANDLE CreateFileMapping( HANDLE hFile, LPSECURITY ATTRIBUTES lpsa, 
DWORD fdwProtect, DWORD dwMaximumSizeHigh, 
DWORD dwMaximumSizeLow, LPSTR lpszMapName ); 


Возвращаемое значение: описатель отображения файла B случае успеха, NULL — 
B случае ошибки. 


LPVOID MapViewOfFile( HANDLE hFileMapObject, DWORD dwDesiredAccess, 
DWORD dwFileOffsetHigh, DWORD dwFileOffsetLow, 
DWORD dwBytesToMap ); 


Возвращаемое значение: адрес, Ha который отображена память, B случае успе- 
xa, NULL — в случае ошибки. 


После создания объект в памяти отображается на адресное пространство каж- 
дого процесса с помощью функции MapViewOfFile.IIapaMerp hFileMapObj — это 
описание, возвращенное после вызова CreateFileMapping. Требуемый уровень 
доступа следует задать с помощью dwDesiredAccess. Этот параметр может при- 
нимать следующие значения: FILE MAP WRITE (доступ на чтение и запись), 
FILE, MAP READ (доступ только на чтение), FILE MAP ALL ACCESS (то же, что 
ЕТЬЕ_МАР_МВТТЕ) и FILE MAP COPY. Если присвоено последнее значение, то при 
попытке записи создается отдельная копия данных. Параметры dwFileOffsetHigh 
И dwFileOffsetLow задают смещение от начала файла, с которого следует начи- 
нать отображение. Нужно отобразить файл целиком, поэтому оба параметра будут 
равны 0. Размер отображаемой области памяти задается с помощью параметра 
dwBytesToMap. 

Подробнее использование мьютексов и отображение памяти B Windows pac- 
сматриваются в книге [Richter 1997]. 

Теперь можно представить версию init, smb для Windows. Как видно из лис- 
тинга 3.31, она очень напоминает версию для UNIX. 


Листинг 3.31. Функция init smb для Windows 


smb.c 


#define FILENAME "./smbfile" 
define lock buf() if ( WaitForSingleObject( mutex, INFINITE )* 
|= WAIT OBJECT. 0 ) \ 

error( 1, errno, "ошибка вызова lock buf " ) 
fdefine unlock buf() if ( !ReleaseMutex( mutex ) )\ 

error( 1, errno, "ошибка вызова unlock buf" ) 
HANDLE mutex; 
void init smb( int init. freelist ) 
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9 X 

10 HANDLE hfile; 
11 HANDLE hmap; 
12 int i; 


13 mutex - CreateMutex( NULL, FALSE, "smbmutex" ); 
14 if ( mutex -- NULL ) 


15 error( 1, errno, "ошибка вызова CreateMutex" ); 

16 hfile - CreateFile( FILENAME, 

17 GENERIC READ | GENERIC, WRITE, 

18 FILE SHARE READ | FILE SHARE WRITE, 

19 NULL, OPEN ALWAYS, FILE ATTRIBUTE NORMAL, NULL ); 

20 if ( hfile -- INVALID HANDLE, VALUE ) 

21 error( 1, errno, "ошибка вызова CreateFile" ); 

22 hmap = CreateFileMapping( hfile, NULL, PAGE READWRITE, 

23 0, NSMB * sizeof( smb t ) + sizeof( int ), "smbarray" ); 


24 smbarray = MapViewOfFile( hmap, FILE MAP WRITE, 0, 0, 0 ); 
25 if ( smbarray == NULL ) 


26 error( 1, errno, "ошибка вызова MapViewOfFile" ); 
27 

28 if ( init freelist ) 

29 ( 

30 for (і = 0; і < NSMB- 1; 1++ ) 

31 smbarray[ i ].nexti = i + 1; 

32 smbarray[ NSMB - 1 ].nexti = -1; 

33 FREE LIST = 0; 

34 } 

35 } 


smb.c 


Для тестирования всей системы следует написать небольшие программы кли- 
ентской (листинг 3.32) и серверной (листинг 3.33) частей. 


Листинг 3.32. Клиент, использующий систему буферов в разделяемой памяти 


smbc.c 
1 £include "etcp.h" 


2 int main( int argc, char **argv ) 


3 1 

4 char *bp; 

5 SOCKET s; 

6 INIT(); 

7 S = tcp client( argv[ 1 ], агаду[ 2 ] ); 

8 init smb( FALSE ); 

9 bp = smballoc(); 

10 while ( fgets( bp, SMBUFSZ, stdin ) !- NULL ) 
11 ( 

12 smbsend( s, bp ); 


13 bp = smballoc(); 
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14 } 
15 EXIT( O ); 
16 ) 
smbc.c 


Листинг 3.33. Сервер, использующий систему буферов B разделяемой памяти 


smbs.c 
1 #іпс1чае "etcp.h" 
2 int main( int argc, char **argv ) 
3 { 
4 char *bp; 
5 SOCKET s; 
6 SOCKET 51; 
7 INIT(); 
8 init. smb( TRUE ); 
9 s = tcp server( NULL, argv[ 1 ] }; 
10 51 = accept( s, NULL, NULL ); 
11 if ( !isvalidsock( s1 ) ) 
12 error( 1, errno, "ошибка вызова accept" ); 
13 for ( ;; ) 
14 { 
15 bp = smbrecv( s1 ); 
16 fputs( bp, stdout ); 
17 smbfree( bp ); 
18 ) 
19 EXIT( 0 ); 
20 ) 
smbs.c 
Запустив эти программы, получите ожидаемый результат: 
bsd: $ smbc localhost 9000 bsd: $ smbs 9000 
Hello Hello 
World! Wolds! 
^C smbs: smbrecv: другой конец отсоединился 
bsd: $ bsd: $ 


Обратите внимание, что smbc читает каждую строку из стандартного ввода 
прямо в буфер в разделяемой памяти, а smbs копирует каждую строку из буфера 
сразу на стандартный вывод, поэтому не возникает лишнего копирования данных. 


Резюме 


В этом разделе описано, как избежать ненужного копирования данных. Во 
многих сетевых приложениях на копирование данных из одного буфера в другой 
тратится большая часть времени процессора. 

Разработана схема взаимодействия между процессами, в которой используется 
система буферов в разделяемой памяти. Это позволило передавать единственный 
экземпляр данных от одного процесса другому. Такая схема работает и в UNIX, 
ив Windows. 
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Хотя обычно используется только три поля из структуры Sockaddr, in: 
sin family,sin portH sin_addr, HO, как правило, B ней есть и другие поля. Ha- 
пример, во многих реализациях есть поле sin, len, содержащее длину структуры. 
В частности, оно присутствует в системах, производных от версии 4.3BSD Reno 
и более поздних. Напротив, в спецификации Winsock этого поля нет. 

Если сравнить структуры sockaddr, in в системе FreeBSD 


struct sockaddr in { 
u_char sin len; 
u charsin family; 
u char sin, port; 
struct in_addr sin, addr; 
char sin, zero[8]; 


}; 
ив Windows 


struct sockaddr. in { 
short sin_family; 
u short sin, port; 
struct in, addr sin адаг; 
char sin zero[8]; 


}; 


то видно, что в обеих структурах есть дополнительное поле sin_zero. Хотя это 
поле и не используется (оно нужно для того, чтобы длина структуры sockaddr in 
была равна в точности 16 байт), но тем не менее должно быть заполнено нулями. 


Примечание Причина в том, что в некоторых реализациях во время привязки 
адреса к сокету производится двоичное сравнение этой адрес- 
ной структуры с адресами каждого интерфейса. Такой код бу- 
дет работать только в том случае, если поле sin zero запол- 
нено нулями. 


Поскольку в любом случае необходимо обнулить поле sin. zero, обычно перед 
использованием адресной структуры ее полностью обнуляют. В этом случае заодно 
очищаются и все дополнительные поля, так что не будет проблем из-за недокумен- 
тированных полей. Посмотрите на листинг 2.3 — сначала в функции set, address 
делается вызов bzero для очистки структуры sockaddr in. 


Совет 28. Не забывайте о порядке байтов 


В современных компьютерах целые числа хранятся по-разному, в зависимости 
от архитектуры. Рассмотрим 32-разрядное число 305419896 (0х12345678). Четы- 
ре байта этого числа могут храниться двумя способами: сначала два старших байта 
(такой порядок называется тупоконечным — big endian) 


12 34 56 78 
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или сначала два младших байта (такой порядок называется остроконечным ~ little 
endian) 


78 56 34 12 


Примечание Термины «тупоконечный» и «остроконечный» ввел Коэн [Cohen 
1981], считавший, что споры о том, какой формат лучше, срод- 
ни распрям лилипутов из романа Свифта «Путешествия Iyn- 
ливера», которые вели бесконечные войны, не сумев договорить- 
ся, с какого конца следует разбивать яйцо — с тупого или острого. 
Раньше были в ходу и другие форматы, но практически во всех 
современных машинах применяется либо тупоконечный, либо 
остроконечный порядок байтов. 


Определить формат, применяемый в конкретной машине, можно с помощью 
следующей текстовой программы, показывающей, как хранится число 0x12345678 
(листинг 3.34). 


Листинг 3.34. Программа для определения порядка байтов 


endian.c 

1 *include <stdio.h> 

2 #include <sys/types.h> 

3 #include "etcp.h" 

4 int main( void ) 

6 

6 u int32 t x = 0х12345678; /* 305419896 */ 

7 unsigned char *хр = ( char * )&x; 

9 printf( "%0х %0х $0х %0х\п", 

10 xp[ 0 ], xpt 1 ], xp[ 2 1, xp[ 3.1 ); 

11 exit( 0 ); 

12 } 
endian.c 


Если запустить эту программу на компьютере c процессором Intel, то получится: 


bsd: $ endian 
78 56 34 12 
bsd: S 


Отсюда ясно видно, это — остроконечная архитектура. 

Конкретный формат хранения иногда в шутку называют полом байтов. Он ва- 
жен, поскольку остроконечные и тупоконечные машины (а равно те, что исполь- 
зуют иной порядок) часто общаются друг c другом по протоколам TCP/IP. Ho- 
скольку такая информация, как адреса отправления и назначения, номера портов, 
длина датаграмм, размеры окон и т.д., представляется в виде целых чисел, необхо- 
димо, чтобы обе стороны интерпретировали их одинаково. 

Чтобы обеспечить взаимодействие компьютеров с разными архитектурами, 
все целочисленные величины, относящиеся к протоколам, передаются в сетевом 
порядке байтов, который по определению является тупоконечным. По большей 
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части, обо всем заботятся сами протоколы, но сетевые адреса, номера портов, 
а иногда и другие данные, представленные в заголовках, вы задаете сами. И вся- 
кий раз необходимо преобразовывать их в сетевой порядок. 

Для этого служат две функции, занимающиеся преобразованием из машинно- 
го порядка байт в сетевой и обратно. Представленные ниже объявления этих функ- 
ций заимствованы из стандарта POSIX. В некоторых версиях UNIX эти объявле- 
ния находятся He в файле netinet/in.h. Типы uint32, t и uint16, t приняты 
в POSIX соответственно для беззнаковых 32- и 16-разрядных целых. В некоторых 
реализациях эти типы могут отсутствовать. Тем не менее функции htonl и ntohl 
всегда принимают и возвращают беззнаковые 32-разрядные целые числа, будь то 
UNIX или Winsock. Точно так же функции htons и ntohs всегда принимают 
и возвращают беззнаковые 16-разрядные целые. 


Примечание Буквы «l» и «s» в конце имен функций означают long (длинное) 
и short (короткое). Это имело смысл, так как первоначально дан- 
ные функции появились в системе 4.2BSD, разработанной для 
32-разрядной машины, где длинное целое принимали равным 
32 бит, а короткое - 16. С появлением 64-разрядных машин это 
уже не так важно, поэтому следует помнить, что [-функции ра- 
ботают с 32-разрядными числами, которые не обязательно пред- 
ставлены xax long, a 5-функции - c 16 разрядными числами, Komo- 
рые не обязательно представлены в виде short. Удобно считать, 
что 1-функции предназначены для преобразования длинных полей 
в заголовках протокола, а 5-функции – коротких полей. 


d$include «netinet/in.h» /* UNIX */ 
dinclude «winsock2.h» /* Winsock */ 


uint32. t htonl( uint32.t host32 ); 
uinti6 t htons( uinti6 t hostí16 ); 


Обе функции возвращают целое число B сетевом порядке. 


uint32, t ntohl( uint32 t network32 ); 
uint16, t ntohs( uinti6 t networkil6 ); 


Обе функции возвращают целое число B машинном порядке. 


Функции htonl и htons преобразуют целое число из машинного порядка байт 
в сетевой, тогда как функции ntohl и ntohs выполняют обратное преобразова- 
ние. Заметим, что на «тупоконечных» машинах эти функции ничего не делают 
и обычно определяются в виде макросов: 


#дӢеҒіпе htonl(x) (x) 


На «остроконечных» машинах (и для иных архитектур) реализация функций 
зависит от системы. Не надо задумываться, на какой машине вы работаете, по- 
скольку эти функции всегда делают то, что нужно. 
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Применение этих функций обязательно только для полей, используемых про- 
токолами. Пользовательские данные для протоколов IP, U DP n TCP выглядят как 
множество неструктурированных байтов, так что неважно, записаны целые числа 
в сетевом или машинном порядке. Тем не менее функции ntoh* и hton* стоит 
применять при передаче любых данных, поскольку тем самым вы обеспечиваете 
возможность совместной работы машин с разной архитектурой. Даже если снача- 
ла предполагается, что приложение будет работать только на одной платформе, 
обязательно настанет день, когда его придется переносить на другую платформу. 
Тогда дополнительные усилия окупятся с лихвой. 


Примечание В общем случае проблема преобразования данных между маши- 
нами с разными архитектурами сложна. Многие программисты 
решают ее, преобразуя все числа в код ASCII (или, возможно, в код 
EBCDIC для больших машин фирмы 1ВМ). Другой подход связан 
с использованием компоненты XDR (External Data Representation — 
внешнее представление данных), входящей в состав подсистемы 
вызова удаленных процедур (RPC — remote procedure call), раз- 
работанной фирмой Sun. Компонента XDR определена в ВЕС 
1832 [Srinivasan 1995] и представляет собой набор правил для 
кодирования данных различных типов, а также язык, описыва- 
ющий способ кодирования. Хотя предполагалось, umo XDR бу- 
дет применяться как часть RPC, можно пользоваться этим 
механизмом в ваших программах. В книге [Stevens 1999] обсуж- 
дается XDR u ezo применение без RPC. 


И, наконец, следует помнить, что функции разрешения имен, такие как 
gethostbyname и getservbyname (совет 29), возвращают значения, представ- 
ленные в сетевом порядке. Поэтому следующий неправильный код 


Struct servent *sp; 

Struct sockaddr in *sap; 

Sp = getservbyname( name, protocol ); 
Sap-»sin port = htons( sp-»s port ); 


приведет к ошибке, если исполняется He Ha «тупоконечной» машине. 


Резюме 


В этом разделе рассказывалось, что в TCP/IP применяется стандартное пред- 
ставление в сетевом порядке байт для целых чисел, входящих в заголовки прото- 
колов. Здесь также приведены функции htonl, htons, ntohl и ntohs, которые 
преобразуют целые из машинного порядка байт в сетевой и обратно. Кроме того, 
было отмечено, что в общем случае для преобразования форматов данных между 
машинами полезно средство ХОК. 


ІР-адреса и номера портов в коде 


Совет 29. He «зашивайте» ІР-адреса и номера 
портов в код 


У программы есть только два способа получить [Р-адрес или номер порта: 


KASR 


О из аргументов в командной строке или, если программа имеет графический 
интерфейс пользователя, с помощью диалогового окна либо аналогичного 


механизма; 

о с помощью функции разрешения имен, например gethostbyname или 
getservbyname. 

Примечание Строго говоря, getservbyname — это не функция разрешения 


имени (то есть она не входит в состав ОМ№5-клиента, который 
отображает имена на ІР-адреса и наоборот). Но oua рассмотре- 
на вместе с остальными, поскольку выполняет похожие действия. 


Никогда не следует «зашивать» эти параметры в текст программы или помещать 
их в собственный (не системный) конфигурационный файл. И в UNIX, и в Windows 
есть стандартные способы получения этой информации, ими и надо пользоваться. 

Теперь ІР-адреса все чаще выделяются динамически с помощью протокола 
DHCP (dynamic host configuration protocol — протокол динамической конфигура- 
ции хоста). И это убедительная причина избегать их задания непосредственно 
в тексте программы. Некоторые считают, что из-за широкой распространенности 
DHCP и сложности адресов в протоколе IPv6 вообще не нужно передавать прило- 
жению числовые адреса, а следует ограничиться только символическими именами 
хостов, которые приложение должно преобразовать в [Р-адреса, обратившись к функ- 
ции gethostbyname или родственным ей. Даже если протокол DHCP не использу- 
ется, управлять сетью будет намного проще, если не «зашивать» эту информацию 
в код и не помещать ее в нестандартные места. Например, если адрес сети изменяет- 
ся, то все приложения с «зашитыми» адресами просто перестанут работать. 

Всегда возникает искушение встроить адрес или номер порта непосредствен- 
но в текст программы, написанной «на скорую руку», и не возиться с функциями 
типа getXbyY. К сожалению, такие программы начинают жить своей жизнью, 
а иногда даже становятся коммерческими продуктами. Одно из преимуществ Kap- 
касов и библиотечных функций на их основе (совет 4) состоит в том, что код уже 
написан, так что нет необходимости «срезать углы». 

Рассмотрим некоторые функции разрешения имен и порядок их применения. 
Вы уже не раз встречались с функцией gethostbyname: 


Kinclude «netdb.h-» /* UNIX */ 
Kinclude «winsock2.h» /* Winsock */ 


struct hostent *gethostbyname( const char *name ); 


Возвращаемое значение: указатель Ha структуру hostent B случае успеха, 
NULL и код ошибки в переменной h. errno - в случае неудачи. 
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Функции gethostbyname передается имя хоста, а она возвращает указатель 
на структуру hostent следующего вида: 


struct hostent { 


char *h name; /* Официальное имя хоста. */ 

char **h aliases; /* Список синонимов. */ 

int h addrtype; /* Тип адреса хоста. */ 

int h length; /* Длина адреса. */ 

char **h addr list; /* Список адресов, полученных OT DNS. */ 


fdefine h addr h адаг list[0]; /* Первый адрес. */ 
1 


Поле h, name указывает на «официальное» имя хоста, а поле h. aliases — на спи- 
сок синонимов имени. Поле h, addrtype содержит либо АЕ_ТМЕТ, либо AF. INET6 
взависимости от того, составлен ли адрес в соответствии с протоколом IPv4 или IPv6. 
Аналогично поле h. length равно 4 или 16 в зависимости от типа адреса. Все адреса 
типа h, addrtype возвращаются в списке, на который указывает поле h. addr. list. 
Макрос h, addr выступает B роли синонима первого (возможно, единственного) адре- 
са B этом списке. Поскольку gethostbyname возвращает список адресов, приложение 
может попробовать каждый из них, пока не установит соединение с нужным хостом. 

Работая с функцией gecthostbyname нужно учитывать следующие моменты: 


О если хост поддерживает оба протокола IPv4 и IPv6, то возвращается только 
один тип адреса. B UNIX тип возвращаемого адреса зависит от параметра 
RES USE INET6 системы разрешения имен, который можно явно задать, обра- 
тившись к функции res init или установив переменную среду, а также 
с помощью опции в конфигурационном файле DNS. В соответствии с Win- 
sock, всегда возвращается адрес IPv4; 

О структура hostent находится в статической памяти. Это означает, что функ- 
ция gethostbyname не рентабельна; 

о указатели, хранящиеся в статической структуре hostent, направлены на 
другую статическую или динамически распределенную память, поэтому при 
желании скопировать структуру необходимо выполнять глубокое копирова- 
ние. Это означает, что помимо памяти для самой структуры hostent необ- 
ходимо выделить память для каждой области, на которую указывают поля 
структуры, а затем скопировать в нее данные; 

О как говорилось в совете 28, адреса, хранящиеся в списке, на который указы- 
вает поле h. addr. list, уже приведены к сетевому порядку байтов, так что 
применять к ним функцию hton1 не надо. 


Вы можете также выполнить обратную операцию — отобразить адреса хостов 
на их имена. Для этого служит функция gethostbyaddr. 


d&include «netdb.h» /* UNIX. */ 
Kinclude «winsock2.h» /* Winsock. */ 


struct hostent *gethostbyaddr( const char *addr, int len, int type ); 


Возвращаемое значение: указатель на структуру hostent в случае успеха, 
NULL и код ошибки в переменной h, errno — в случае неудачи. 
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Несмотря на то, что параметр addr имеет тип char *, он указывает на структу- 
ру in_addr (или in6, adár в случае IPv6). Длина этой структуры задается Napa- 
метром len, а ее тип (АЕ_ТМЕТ или AF, INET6) — параметром type. Предыдущие 
замечания относительно функции gethostbyname касаются и gethostbyadüór. 

Для хостов, поддерживающих протокол IPv6, функции gethostbyname недо- 
статочно, так как нельзя задать тип возвращаемого адреса. Для поддержки IPv6 
(и других адресных семейств) введена общая функция gethostbyname2, допус- 
кающая получение адресов указанного типа. 


finclude «netdb.h» /* UNIX */ 


int af ); 


struct hostent *gethostbyname2( const char *name, 


Возвращаемое значение: указатель Ha структуру hostent в случае успеха, 
NULL и код ошибки в переменной h. errno — в случае неудачи. 


Параметр аЁ- это адресное семейство. Интерес представляют только возмож- 
ные значения AF. INET ИЛИ AF. INET6. Спецификация Winsock не определяет функ- 
цию gethostbyname2, а использует вместо нее функционально более богатый 
(и сложный) интерфейс WSALookupServiceNext. 


Примечание Взаимодействие протоколов 1Ро4 и [Руб — это в значительной 
мере вопрос обработки двух разных типов адресов. И функция 
gethostbyname2 предлагает один из способов решения этой 
проблемы. Эта тема подробно обсуждается в книге [Stevens 
1998], где также приведена реализация описанной в стандарте 
POSIX функции getaddrinfo. Эта функция дает удобный, не 
зависящий от протокола способ работы с обоими типами адре- 
сов. С помощью getaddrinfo можно написать приложение, ко- 
mopoe будет одинаково работать и с ІРо4, и c IPv6. 


Раз системе (или службе DNS) разрешено преобразовывать имена хостов в [Р- 
адреса, почему бы ни сделать то же и для номеров портов? В совете 18 рассматри- 
вался один способ решения этой задачи, теперь остановимся на другом. Так же, 
как gethostbyname и gethostbyaddr выполняют преобразование имени хоста 
в адрес и обратно, функции getservbyname и getservbyport преобразуют сим- 
волическое имя сервиса в номер порта и наоборот. Например, сервис времени дня 
daytime прослушивает порт 13 в ожидании ТСР-соединений или ОПР-дата- 
грамм. Можно обратиться к нему, например, с помощью программы telnet: 


telnet bsd 13 


Однако необходимо учитывать, что номер порта указанного сервиса равен 13. 
К счастью, telnet понимает и символические имена портов: 


telnet bsd daytime 


Telnet выполняет отображение символических имен на номера портов, вы- 
зывая функцию getservbyname; вы сделаете то же самое. В листинге 2.3 вы 
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увидите, что в предложенном каркасе этот вызов уже есть. Функция set, address 
сначала оперирует параметром port как представленным в коде ASCII це- 
лым числом, то есть пытается преобразовать его в двоичную форму. Если это 
не получается, то вызывается функция getservbyname, которая ищет в базе 
данных символическое имя порта и возвращает соответствующее ему число- 
вое значение. 

Прототип функции getservbyname похож на gethostbyname: 


#include «netdb.h» /* UNIX */ 
#include «winsock2.h» /* Winsock */ 


struct servent *getservbyname( const char *name, const char *proto ); 


Возвращаемое значение: указатель на структуру servent в случае успеха, 
NULL - в случае неудачи. 


Параметр name — это символическое имя сервиса, например «daytime». Если 
параметр proto не равен NULL, то возвращается сервис, соответствующий задан- 
ным имени и типу протокола, в противном случае — первый найденный сервис 
с именем name, Структура servent содержит информацию о найденном сервисе: 


struct servent { 


char *ѕ name; /* Официальное имя сервиса. */ 
char **5_а11азез; /* Список синонимов. */ 

int s, port; /* Номер порта. */ 

char *s, proto; /* Используемый протокол. */ 


E 


Поля s, name и s, aliases содержат указатели Ha официальное имя сервиса 
и его синонимы. Номер порта сервиса находится в поле s, port. Как обычно, этот 
номер уже представлен в сетевом порядке байтов. Протокол (ТСР или UDP), ис- 
пользуемый сервисом, описывается строкой в поле s. proto. 

Вы можете также выполнить обратную операцию — найти имя сервиса по HO- 
меру порта. Для этого служит функция getservbyport: 


#include «netdb.h» /* UNIX. */ 
finclude «winsock2.h» /* Winsock. */ 


struct servent *getservbyport( int port, const char *proto ); 


Возвращаемое значение: указатель на структуру servent B случае успеха, 
NULL - в случае неудачи 


Передаваемый в параметре port номер порта должен быть записан в сетевом 
порядке. Параметр proto имеет тот же смысл, что и раньше. 

С точки зрения программиста, данный каркас и библиотечные функции ре- 
шают задачи преобразования имен хостов и сервисов. Они сами вызывают нуж- 
ные функции, а как это делается, не должно вас волновать. Однако нужно знать, 
как ввести в систему необходимую информацию. 
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Обычно это делается с помощью одного из трех способов: 


а DNS; 
о сетевой информационной системы (NIS) или NIS+; 
a файлов hosts и services. 


DNS (Domain Name System — служба доменных имен) — это распределенная 
база данных для преобразования имен хостов в адреса. 


Примечание DNS используется также для маршрутизации электронной почты. 
Когда посылается письмо на адрес jsmith&somecompany. com, 
с помощью DNS ищется обработчик (или обработчики) почты 
для компании вотесотрапу . сот. Подробнее это объясняется 
e книге [Albitz and Lin 1998]. 


Ответственность за хранение данных распределяется между зонами (грубо гово- 
ря, они соответствуют адресным доменам) и подзонами. Например, bigcompany.com 
может представлять собой одну зону, разбитую на несколько подзон, соответству- 
ющих отделам или региональным отделениям. В каждой зоне и подзоне работает 
один или несколько О№$-серверов, на которых хранится вся информация о хостах 
в этой зоне или подзоне. Другие DNS-cepBepbr могут запросить информацию y дан- 
ных серверов для разрешения имен хостов, принадлежащих компании BigCompany. 


Примечание Система DNS — это хороший пример ОРР-приложения. Как npa- 
вило, обмен с ОМ5-сервером происходит короткими транзакци- 
ями. Клиент (обычно одна из функций разрешения имен) посы- 
лает UDP-ðamazpammy, содержащую запрос к DNS-cepeepy. 
Если в течение некоторого времени ответ не получен, то пробу- 
ется другой сервер, если таковой известен. В противном случае 
повторно посылается запрос первому серверу, но с увеличенным 
тайм-аутом. 


На сегодняшний день подавляющее большинство преобразований между име- 
нами хостов и [Р-адресами производится с помощью службы DNS. Даже сети, не 
имеющие выхода вовне, часто пользуются DNS, так как это упрощает администри- 
рование. При добавлении в сеть нового хоста или изменении адреса существующего 
нужно обновить только базу данных DNS, а не файлы hosts на каждой машине. 

Система NIS и последовавшая за ней NIS+ предназначены для ведения центра- 
лизованной базы данных о различных аспектах системы. Помимо имен хостов 
и [Р-адресов, NIS может управлять именами сервисов, паролями, группами и Apy- 
гими данными, которые следует распространять по всей сети. Стандартные функ- 
ции разрешения имен (о них говорилось выше) могут опрашивать и базы данных 
NIS. В некоторых системах NIS-cepsep при получении запроса на разрешение име- 
ни хоста, о котором y него нет информации, автоматически посылает запрос DNS- 
серверу. В других системах этим занимается функция разрешения имен. 

Преимущество системы NIS в том, что она централизует хранение всех рас- 
пространяемых по сети данных, упрощая тем самым администрирование больших 
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сетей. Некоторые эксперты не рекомендуют NIS, так как имеется потенциальная 
угроза компрометации паролей. В системе NIS+ эта угроза снята, но все равно 
многие опасаются пользоваться ей. NIS обсуждается в работе [Brown 1994]. 

Последнее и самое неудобное из стандартных мест размещения информации 
об именах и ІР-адресах хостов — это файл hosts, обычно находящийся в каталоге 
/etc на каждой машине. В этом файле хранятся имена, синонимы и ІР-адреса xo- 
стов в сети. Стандартные функции разрешения имен просматривают также и этот 
файл. Обычно при конфигурации системы можно указать, когда следует просмат- 
ривать файл hosts — до или после обращения к службе DNS. 

Другой файл — обычно /etc/services — содержит информацию о coorBer- 
ствии имен и портов сервисов. Если NIS не используется, то, как правило, Ha каж- 
дой машине имеется собственная копия этого файла. Поскольку он изменяется 
редко, с его администрированием не возникает таких проблем, как с файлом host s. 
В совете 17 было сказано о формате файла services. 

Основной недостаток файла host s — это очевидное неудобство ero сопровож- 
дения. Если в сети более десятка хостов, то проблема быстро становится почти не- 
разрешимой. В результате многие эксперты рекомендуют полностью отказаться OT 
такого метода. Например, в книге [Lehey 1996] советуется следующее: «Есть толь- 
ко одна причина не пользоваться службой DNS — если ваш компьютер не подсое- 
динен к сети». 


Резюме 


В этом разделе рекомендовано не «зашивать» адреса и номера портов в про- 
грамму. Также рассмотрено несколько стандартных схем получения этой инфор- 
мации и обсуждены их достоинства и недостатки. 


Совет 30. Разберитесь, что такое подсоединенный 
UDP-coker 


Здесь рассказывается об использовании вызова connect применительно 
к протоколу UDP. Из совета 1 вам известно, что UDP - это протокол, не требую- 
щий установления соединений. Он передает отдельные адресованные конкретно- 
му получателю датаграммы, поэтому кажется, что слово «connect» (соединить) тут 
неуместно. Следует, однако, напомнить, что в листинге 3.6 вы уже встречались 
с примером, где вызов connect использовался B запускаемом через inetd UDP- 
сервере, чтобы получить (эфемерный) порт для этого сервера. Только так inetd 
мог продолжать прослушивать датаграммы, поступающие в исходный хорошо H3- 
вестный порт. 

Прежде чем обсуждать, зачем нужен вызов connect для UDP-cokera, вы дол- 
жны четко представлять себе, что собственно означает «соединение» в этом кон- 
тексте. При использовании ТСР вызов connect инициирует обмен информацией 
о состоянии между сторонами с помощью процедуры трехстороннего квитирова- 
ния (рис. 3.14). Частью информации о состоянии является адрес и порт каждой 
стороны, поэтому можно считать, что одна из функций вызова connect в прото- 
коле TCP - это привязка адреса и порта удаленного хоста к локальному сокету. 
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Хотя полезность вызова connect в протоколе UDP может показаться сомни- 
тельной, но вы увидите, что, помимо некоторого повышения производительнос- 
ти, он позволяет выполнить такие действия, которые без него были бы невозмож- 
ны. Рассмотрим причины использования соединенного сокета UDP сначала 
с точки зрения отправителя, а потом — получателя. 

Прежде всего, от подсоединенного UDP-coxkera вы получаете возможность HC- 
пользования вызова send или write (B UNIX) вместо sendto. 


Примечание Для подсоединенного UDP-coxema можно использовать и вызов 
sendto, но в качестве указателя на адрес получателя надо за- 
давать NULL, a в качестве его длины — нуль. Возможен, конечно, 
и вызов sendmsg, но и в этом случае поле msg. name в структуре 
msghdr должно содержать NULL, а поле msg. namelen — нуль. 


Само по себе это, конечно, немного, но все же вызов connect действительно 
дает заметный выигрыш в производительности. 

В реализации BSD sendto - это частный случай connect. Когда датаграмма 
посылается с помощью Sendto, ядро временно соединяет сокет, отправляет дата- 
грамму, после чего отсоединяет сокет. Изучая систему 4.3BSD и тесно связан- 
ную с ней SunOS 4.1.1, Партридж и Пинк [Partridge and Pink 1993] заметили, что 
такой способ соединения и разъединения занимает почти треть времени, уходяще- 
го на передачу датаграммы. Если не считать усовершенствования кода, который 
служит для поиска управляющего блока протокола (PCB - protocol control block) 
и ассоциирован с сокетом, исследованный этими авторами код почти без измене- 
ний вошел в систему 4.4BSD и основанные на ней, например FreeBSD. В частно- 
сти, эти стеки по-прежнему выполняют временное соединение и разъединение. 
Таким образом, если вы собираетесь посылать последовательность ОРР-дата- 
грамм одному и тому же серверу, то эффективность можно повысить, предвари- 
тельно вызвав connect. 

Этот выигрыш B производительности характерен только для некоторых pea- 
лизаций. А основная причина, по которой отправитель ОЮР-датаграмм подсоеди- 
няет сокет, — это желание получать уведомления об асинхронных событиях. Пред- 
ставим, что надо послать ОЮР-датаграмму, но никакой процесс на другой стороне 
не прослушивает порт назначения. Протокол UDP на другом конце вернет ICMP- 
сообщение о недоступности порта, информируя тем самым ваш стек TCP/IP, но 
если сокет не подсоединен, то приложение не получит уведомления. Когда вы вы- 
зываете зеп фо, в начало сообщения добавляется заголовок, после чего оно nepe- 
дается уровню IP, где инкапсулируется в [Р-датаграмму и помещается B выход- 
ную очередь интерфейса. Как только датаграмма внесена в очередь (или отослана, 
если очередь пуста), sendto возвращает управление приложению с кодом нор- 
мального завершения. Иногда через некоторое время (отсюда и термин асинхрон- 
ный) приходит ІСМР-сообщение от хоста на другом конце. Хотя в нем есть копия 
ОРР-заголовка, у вашего стека нет информации о том, какое приложение посы- 
лало датаграмму (вспомните совет 1, где говорилось, что из-за отсутствия уста- 
новленного соединения система сразу забывает об отправленных датаграммах). 


HJARA создание эффективных сетевых программ 


Если же сокет подсоединен, то этот факт отмечается в управляющем блоке прото- 
кола, связанном с сокетом, и стек TCP/IP может сопоставить полученную копию 
ОПрР-заголовка с тем, что хранится в РСВ, чтобы определить, в какой сокет Ha- 
править ІСМР-сообщение. 

Можно проиллюстрировать данную ситуацию с помощью вашей программы 
udpclient (листинг 3.5) из совета 17 — следует отправить датаграмму в порт, ко- 
торый не прослушивает ни один процесс: 


bsd: $ udpclient bsd 9000 

Hello, Worldi 

^C Клиент "зависает" и прерывается вручную. 
bsd: $ 


Теперь модифицируем клиент, добавив такие строки 


if ( connect( s, ( struct sockaddr * )&peer, sizeof( peer ) ) ) 
error( 1, errno, "ошибка вызова connect" ); 


сразу после вызова функции udp, client. Если назвать эту программу udpconni 
и запустить ее, то вы получите следующее: 


bsd: $ udpconni bed 9000 

Hello, World! 

updconnli: ошибка вызова sendto: Socket is already connected (56) 
bsd: $ 


Ошибка произошла из-за того, что вы вызвали sendto для подсоединенного 
сокета. При этом sendto потребовал от UDP временно подсоединить сокет. Но 
UDP определил, что сокет уже подсоединен и вернул код ошибки ETSCONN. 

Чтобы исправить ошибку, нужно заменить обращение к sendto на 


rc = send( s, buf, strlen( buf ), 0 ); 


Назовем новую программу udpconn2. После ee запуска получится такой pe- 
зультат: 


bsd: $ udpconni bsd 9000 
Hello, World! 


updconn2: ошибка вызова recvfrom: Connection refused (61) 
bsd: $ 


На этот раз ошибку ECONNREFUSED вернул вызов recvfrom. Эта ошибка — pe- 
зультат получения приложением ІСМР-сообщения о недоступности порта. 

Обычно у получателя нет причин соединяться с отправителем (если, конечно, 
ему самому не нужно стать отправителем). Однако иногда такая ситуация может 
быть полезна. Вспомним аналогию с телефонным разговором и почтой (совет 1). 
ТСР-соединение похоже на частный телефонный разговор — в нем только два участ- 
ника. Поскольку в протоколе ТСР устанавливается соединение, каждая сторона зна- 
ет о своем партнере и может быть уверена, что всякий полученный байт действи- 
тельно послал партнер. 

С другой стороны, приложение, получающее 7 ЮР-датаграммы, можно срав- 
нить с почтовым ящиком. Как любой человек может отправить письмо по данному 
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адресу, так и любое приложение или хост может послать приложению-получате- 
лю датаграмму, если известны адрес и номер порта. 

Иногда нужно получать датаграммы только от одного приложения. Получаю- 
щее приложение добивается этого, соединившись со своим партнером. Чтобы уви- 
деть, как это работает, напишем UDP-cepBep эхо-контроля, который соединяется 
с первым клиентом, отправившим датаграмму (листинг 3.35). 


Листинг 3.35. UDP-cepBep эхо-контроля, выполняющий соединение 


udpconnserv.c 
1 $include "etcp.h" 
2 int main( int argc, char **argv ) 
3 { 
4 struct sockaddr in peer; 
5 SOCKET s; 
6 int rc; 
7 int len; 
8 char buff 120 ]; 


9 INIT(); 
10 S = чар server( NULL, argv[ 1 ] ); 
11 len = sizeof( peer ); 
12 rc - recvfrom( s, buf, sizeof( buf ), 
13 0, ( struct sockaddr * )&peer, &len ); 
14 if (rc «0) 
15 error( 1, errno, "ошибка вызова recvfrom" ); 
16 if ( connect( s, ( struct sockaddr * )&peer, len ) ) 
17 error( 1, errno, "ошибка вызова connect" ); 
18 while ( strncmp( buf, "done", 4) != 0) 
19 ( 
20 if ( send( s, buf, rc, 0) < 0) 
21 error( 1, errno, "ошибка вызова send" ); 
22 rc = recv( s, buf, sizeof( buf ), 0 ); 
23 if (re < 0) 
24 error( 1, errno, "ошибка вызова recv" ); 
25 H 
26 EXIT( O ); 
27 ) 


udpconnserv.c 


9-15 Выполняем стандартную инициализацию UDP и получаем первую дата- 
грамму, сохраняя при этом адрес и порт отправителя в переменной peer. 

16-17 Соединяемся с отправителем. 

18-25 В цикле отсылаем копии полученных датаграмм, пока не придет дата- 
грамма, содержащая единственное слово «done». 


Для экспериментов с сервером udpconnserv можно воспользоваться клиен- 
том udpconn2. Сначала запускается сервер для прослушивания порта 9000 в ожи- 
дании датаграмм: 


ES создание эффективных сетевых программ 


udpconnserv 9000 


а затем запускаются две копии udpconn2, каждая в своем окне. 


bsd: $ udpconn2 bsd 9000 bsd: $ udpconn2 bsd 9000 

one two 

one udpconn2: ошибка вызова recvfrom: 
Connection refused (61) 

three bsd: $ 

three 

done 

ќе: 

рѕа: $ 


Когда в первом окне вы набираете опе, сервер udpconnserv возвращает ко- 
пию датаграммы. Затем во втором окне вводите Е мо, но гесу rom возвращает код 
ошибки ECONNREFUSED. Это происходит потому, что UDP вернул ІСМР-сообще- 
ние о недоступности порта, так как ваш сервер уже соединился с первым экзем- 
пляром udpconn2 и не принимает датаграммы с других адресов. 


Примечание Адреса отправителя у обоих экземпляров udpconn2, конечно, оди- 
наковы, но эфемерные порты, выбранные стеком TCP/IP, различны. 
В первом окне вы набираете three, дабы убедиться, umo udp- 
connserv все еще функционирует, а затем — done, чтобы 
остановить сервер. В конце прерываем вручную первый экзем- 
пляр udpconn2. 


Как видите, udpconnserv не только отказывается принимать датаграммы OT 
другого отправителя, но также информирует приложение об этом факте, посылая 
[СМР-сообщение. Разумеется, чтобы получить это сообщение, клиент также дол- 
жен подсоединиться к серверу. Если бы вы прогнали этот тест с помощью перво- 
начальной версии клиента udpclient вместо udpconn2, то второй экземпляр кли- 
ента просто «завис» после ввода слова «done». 


Резюме 


В этом разделе рассмотрено использование вызова connect в протоколе UDP. 
Хотя на первый взгляд может показаться, что для протокола без установления со- 
единения это не имеет смысла, но, как вы видели, такое действие, во-первых, по- 
вышает производительность, а во-вторых, оно необходимо при желании получать 
некоторые сообщения об ошибках при отправке ОРЮР-датаграмм. Здесь также опи- 
сано, как использовать connect для приема датаграмм только от одного хоста. 


Совет 31. Помните, что С - не единственный 
язык программирования 


До сих пор все примеры в этой книге были написаны на языке С, но, конечно, 
это не единственно возможный выбор. Многие предпочитают писать на C++, Java 
или даже Pascal. В этом разделе будет рассказано об использовании языков сценари- 
ев для сетевого программирования и приведено несколько примеров на языке Perl. 
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Вы уже встречались с несколькими примерами небольших программ, напи- 
санных специально для тестирования более сложных приложений. Например, 
в совете 30 использованы простые и похожие программы udpclient,udpconni 
и udpconn2 для проверки поведения подсоединенного UDP-coxera. В таких слу- 
чаях имеет смысл воспользоваться каким-либо языком сценариев. Сценарии про- 
ще разрабатывать и модифицировать хотя бы потому, что их не надо компилиро- 
вать и компоновать со специальной библиотекой, а также создавать файлы сборки 
проекта (Makefile) — достаточно написать сценарий и сразу же запустить ero. 

В листинге 3.36 приведен текст минимального Рег|-сценария, реализующего 
функциональность программы udpclient. 

Хотя я не собираюсь писать руководство по языку Perl, но этот пример стоит 
изучить подробнее. 


Примечание Глава 6 стандартного учебника по Рей [Wall et al. 1996] посвящена 
имеющимся в этом языке средствам межпроцессного взаимодей- 
ствия и сетевого программирования. Дополнительную инфор- 
мацию о языке Perl можно найти на сайте http;//wwwperl.com. 


Листинг 3.36. Версия программы udpclient на языке Perl 


pudpclient 
1 4$! /usr/bin/perl5 
2 use Socket; 
3 $host = shift || "localhost"; 
4 $port = shift || "echo"; 
5 $port = getservbyname( $port, "udp" ) if $port =~ /\р/; 
6 $peer = sockaddr in( $port, inet aton( $host ) ); 
7 socket( S, PF INET, SOCK,DGRAM, 0 ) || die "ошибка вызова socket $1"; 
8 while ( $line = <STDIN> ) 
9.1 
10 defined( send( S, $line, 0, $peer ) ) || die "ошибка вызова send $!"; 
11 defined( recv( S, $line, 120, 0) ) || die "ошибка вызова recv $!"; 
12 print $line; 
13 ) 
pudpclient 
Инициализация 
2 В этой строке Рег] делает доступными сценарию определения некото- 


рых констант (например, РЕ_ТМЕТ). 


Получение параметров командной строки 

3-4 Из командной строки читаем имя хоста и номер порта. Обратите вни- 
мание, что этот сценарий делает больше, чем программа на языке С, так 
как по умолчанию он присваивает хосту имя localhost, а порту – 
echo, если один или оба параметра не заданы явно. 


Заполнение структуры ѕоскайаг іп и получение сокета 


5-6 Этот код выполняет Te же действия, что и функция set, address в ЛИ- 
стинге 2.3 в совете 4. Обратите внимание на простоту кода. В этих двух 


ЕЛИНИН ИИИ: создание эффективных сетевых программ 


строчках ІР-адрес хоста принимается как числовой и его имя симво- 
лическое, а равно числовое или символическое имя сервиса. 
/ Получаем UDP-coxer. 


Основной цикл 

8-13 Так же, как Budpclient, читаем строки из стандартного ввода, отправ- 
ляем их удаленному хосту, читаем от него ответ и записываем его на 
стандартный вывод. 


Хотя знакомые сетевые функции иногда принимают несколько иные аргумен- 
ты и могут возвращать результат непривычным образом, но, в общем, программа 
в листинге 3.36 кажется знакомой и понятной. Тот, кто знаком с основами сетевого 
программирования и хотя бы чуть-чуть разбирается в Perl, может добиться высо- 
кой производительности. 

Для сравнения в листинге 3.37 представлен ТСР-сервер эхо-контроля. Вы мо- 
жете соединиться с этим сервером с помощью программы telnet или любого друго- 
го ТСР-приложения, способного вести себя как клиент эхо-сервера. 

Здесь также видна знакомая последовательность обращений к АРІ сокетов 
и, даже не зная языка Perl, можно проследить за ходом выполнения программы. 
Следует отметить две особенности, присущие Perl: 


О вызов accept на строке 11 возвращает TRUE, если все хорошо, а новый CO- 
кет возвращается во втором параметре (57). В результате естественно выг- 
лядит цикл for, в котором принимаются соединения; 

О поскольку гесу возвращает адрес отправителя (или специальное значение 
undef), a не число прочитанных байт, получая длину строки $line (строка 
16), следует явно проверять, не пришел ли признак конца файла. Оператор 
last выполняет те же действия, что break в языке С. 


Листинг 3.37. Версия эхо-сервера на языке Реп 


pechos 
І #! /usr/bin/perl5 
2 use Socket; 
3 Sport = shift; 
4 $port = getservbyname( $port, 'tcp' ) if $port =~ /\D/; 
5 die "Invalid port" unless $port; 
6 socket( S, PF INET, SOCK STREAM, 0 ) || die "socket: $!"; 
7 setsockopt( S, SOL SOCKET, SO REUSEADDR, pack( '1', 1) ) HI 
8 die "setsockopt: $!"; 
9 bind( S, sockaddr, in( $port, INADDR ANY ) ) || die "bind: $!"; 
10 listen( S, SOMAXCONN ); 
11 for( ; accept( S1, S ); close( S1 ) ) 
12 ( 
13 while ( TRUE ) 
14 ( 
15 defined( recv( S1, $line, 120, 0) ) || die "Гесу: $1"; 


16 last if length( $line ) == 0; 
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17 defined( send( S1, $line, 0 ) ) || die "send: $!"; 
18 } 
19 } 
pechos 


Как видно из этих двух примеров, языки сценариев вообще и Perl в частности — 
это отличный инструмент для написания небольших тестовых программ, создания 
прототипов более крупных систем и утилит. Perl и другие языки сценариев активно 
применяются при разработке Web-cepBepos и специализированных №еЬ-клиентов. 
Примеры рассматриваются в книгах [Castro 1998] и [Patchett and Wright 1998]. 

Помимо простоты и скорости разработки прототипа, есть и другие причины 
для использования языков сценариев. Одна из них — наличие в таких языках спе- 
циальных возможностей. Например, Perl обладает прекрасными средствами для 
манипулирования данными и работы с регулярными выражениями. Поэтому во 
многих случаях Рег| оказывается удобнее таких традиционных языков, как С. 

Предположим, что каждое утро вам надо проверять, не появились ли в конферен- 
ции comp.protocols.tcp-ip новые сообщения о протоколах TCP n UDP В листинге 3.38 
приведен каркас Рег|-сценария для автоматизации решения этой задачи. В таком 
виде сценарий не очень полезен, так как он показывает все сообщения от сервера 
новостей, даже старые; отбор сообщений осуществляется довольно грубо. Можно 
было бы без труда модифицировать сценарий, ужесточив критерий отбора, но луч- 
ше оставить его таким, как есть, чтобы не запутаться в деталях языка Perl. Подроб- 
нее протокол передачи сетевых новостей (NNTP) рассматривается в RFC 977 [Kan- 
tor and Lapsley 1986]. 


Листинг 3.38. Реп-сценарий для формирования дайджеста из сетевых конференций 


tcpnews 
#! /usr/bin/perl5 
use Socket; 
$host = inet aton( 'nntp.ix.netcom.com') || die "хост: $1!"; 
$port = getservbyname( 'nntp', 'tcp' ) || die "некорректный порт"; 
Socket( S, PF INET, SOCK STREAM, 0 ) || die "socket: $!"; 
connect( S, sockaddr in( $port, $host ) ) || die "connect: $!"; 
select( S ); 
$l = 1; 


select( STDOUT ); 
print S "group comp.protocols.tcp-ip\r\n"; 
while ( $line = «S» ) 
{ 
last if $line =~ /^211/; 
} 
($rc, $total, $start, $end ) = split( /\s/, $line ); 
print S "xover $start-$end\nquit\r\n"; 


errr на на на њћ 
OY UI i$ UJ NO IP B. O '!0 0 -J Ov Ui i 0 No l5 


17 while ( $line = «S» ) 
18 { 
19 ( $no, $sub, $auth, $date ) = split( /Nt/, $line ); 


ЕУЛИЕ Cosaanne эффективных сетевых программ 


20 print "$no, $sub, $dateMn" if $sub =~ /TCP[UDP/; 
21 ) 
22 close( S ); 
Есрпем9 


Инициализация и соединение с сервером новостей 
2-6 Это написанный на Perl аналог логики инициализации стандартногф 
ТСР-клиента. 


Установить режим небуферизованного ввода/вывода 

7-9 В Perl функция print вызывает стандартную библиотеку ввода/выво 
да, а та, как упоминалось в совете 17, буферизует вывод в сокет. Эт 
три строки отключают буферизацию. Хотя по виду оператор зе1ес 
напоминает системный вызов select, который рассматривался ране 
в действительности он просто указывает, какой файловый дескрипто; 
будет использоваться по умолчанию. Выбрав дескриптор, вы может 
отменить буферизацию вывода в сокет S, задав ненулевое значение спе 
циальной переменной $ |, используемой B Perl. 


Примечание Строго говоря, это не совсем так. Эти действия приводя 
к тому, что после каждого вызова write или print для данног 
дескриптора автоматически выполняется функция ££1ush. Н 
результат оказывается таким же, как если бы вывод в соке 


был не буферизован. 
у 


В строке 9 stdout восстанавливается как дескриптор по умолчанию. 


Выбрать группу comp.protocols.tcp-ip 

10-14 Посылаем серверу новостей команду group, которая означает, что Te 
кущей группой следует сделать comp.protocols.tcp-ip. Сервер т) 
вечает строкой вида 


211 total articles first articles last articles group namespace 


B строке 13 вы ищете именно такой ответ, отбрасывая все строки, кото 

рые начинаются не с кода ответа 211. Обратите внимание, что операто 

<...> сам разбивает на строки входной поток, поступающий от ТС 
15-16 Обнаружив ответ на команду group, нужно послать серверу строки 


xover first articlefs-last articlet 
quit 


Команда xover запрашивает сервер, заголовки всех статей с номерами из за 
данного диапазона. Заголовок содержит список данных, разделенных символам 
табуляции: номер статьи, тема, автор, дата и время, идентификатор сообщени 
идентификаторы сообщений для статей, на которую ссылается данная, число бай 
тов и число строк. Команда quit приказывает серверу разорвать соединение, таю 
как запросов больше не будет. 
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Отбор заголовков статей 

17-20 Читаем каждый заголовок, выделяем из него интересующие нас поля 
и оставляем только те заголовки, для которых в теме присутствует стро- 
ка «ТСР» или «ОПР». 

Запуск Есрпемз дает следующий результат: 


bsd: $ tcpnews 

74179, Re: UDP multicast, Thu, 22 Jul 1999 21:06:47 GMT 

74181, Re: UDP multicast, Thu, 22 Jul 1999 21:10:45 -0500 

74187, Ве: UDP multicast, Thu, 22 Jul 1999 23:23:00 +0200 

74202, Re: NT 4.0 Server and TCP/IP, Fri, 23 Jul 1999 11:56:07 GMT 
74227, New Seiko TCP/IP Chip, Thu, 22 Jul 1999 08:39:09 -0500 
74267, WATTCP problems, Mon, 26 Jul 1999 13:18:14 -0500 

74277, Re: New Seiko TCP/IP Chip, Thu, 26 Jul 1999 23:33:42 GMT 
74305, ТСР Petri Net model, Wed, 28 Jul 1999 02:27:20 +0200 

bsd: $ 


Помимо языка Perl, есть и другие языки сценариев, пригодные для сетевого 
программирования, например: 


о TCL/Expect; 

a Python; 

о JavaScript; 

о Visual Basic (для Windows). 


Их можно использовать для автоматизации решения простых сетевых задач, 
построения прототипов и быстрого создания удобных утилит или тестовых при- 
меров. Как вы видели, языки сценариев часто проще применять, чем традицион- 
ные компилируемые языки программирования, поскольку интерпретатор берет на 
себя многие технические детали (конечно, расплачиваясь эффективностью). Уси- 
лия, потраченные на овладение хотя бы одним из таких языков, окупятся ростом 
производительности труда. 


Резюме 


В этом разделе говорилось об использовании языков сценариев в сетевом про- 
граммировании. Нередко их применение имеет смысл при написании небольших 
утилит и тестовых программ. 


Совет 32. Определите, на что влияют размеры буферов 


Здесь приводятся некоторые эвристические правила для задания размеров 
буферов приема и передачи в ТСР B совете 7 обсуждалось, как задавать эти раз- 
меры с помощью функции setsockopt. Теперь вы узнаете, какие значения следу- 
ет устанавливать. 

Необходимо сразу отметить, что выбор правильного размера буфера зависит 
от приложения. Для интерактивных приложений типа telnet желательно устанав- 
ливать небольшой буфер. Этому есть две причины: 
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о обычно клиент посылает небольшой блок данных серверу и ждет ответа. По- 
этому выделять большой буфер для таких соединений — пустая трата сис- 
темных ресурсов; 

о при большом буфере реакция на действия пользователя происходит не 
сразу. Например, если пользователь выводит на экран большой файл и на- 
жимает комбинацию клавиш прерывания (Ctrl+C), то вывод не прекратит- 
ся, пока в буферах есть данные. Если буфер велик, то до реального прерыва- 
ния просмотра может пройти заметное время. 


Знать размер буфера необходимо для расчета максимальной производитель- 
ности. Например, это относится к приложениям, которые передают большие объе- 
мы данных преимущественно в одном направлении. Далее будут рассматриваться 
именно такие приложения. 

Как правило, для получения максимальной пропускной способности рекомен- 
дуется, чтобы размеры буферов приема и передачи были не меньше произведения 
полосы пропускания на задержку. Как вы увидите, это правильный, но не слишком 
полезный совет. Прежде чем объяснять причины, разберемся, что представляет 
собой это произведение и почему размер буферов «правильный». 

Вы уже несколько раз встречались с периодом кругового обращения (КТТ). 
Это время, которое требуется пакету на «путешествие» от одного хоста на другой 
и обратно. Оно и представляет собой множитель «задержки», поскольку опреде- 
ляет время между моментом отправки пакета и подтверждением его получателем. 
Обычно RTT измеряется в миллисекундах. 

Другой множитель в произведении — полоса пропускания (bandwidth). Это ко- 
личество данных, которое можно передать в единицу времени по данному физи- 
ческому носителю. 


Примечание Технически это не совсем корректно, но этот термин уже дав- 
но используется. 


Полоса пропускания измеряется в битах в секунду. Например, для сети Ethernet 
полоса пропускания (чистая) равна 10 Мбит/с. 

Произведение полосы пропускания на задержку BWD вычисляется по фор- 
муле: 


BWD = bandwidth X RTT. 
Если RTT выражается в секундах, то единица измерения BWD будет следу- 
ющей: 


бит 
BWD = ——————— X секунда = бит. 
секунда 


Если представить коммуникационный канал как «трубу», то произведение 
полосы пропускания на задержку — это объем трубы в битах (рис. 3.15), то есть 
количество данных, которые могут находиться в сети в любой момент времени. 
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Рис. 3.15 Труба емкостью ВИО бит 


А теперь представим, как выглядит эта труба в установившемся режиме (пос- 
ле завершения алгоритма медленного старта) при массовой передаче данных, за- 
нимающей всю доступную полосу пропускания. Отправитель слева на рис. 3.16 
заполнил трубу ТСР-сегментами и должен ждать, пока сегмент п покинет сеть. 
Только после этого он сможет послать следующий сегмент. Поскольку в трубе на- 
ходится столько же сегментов АСК, сколько и сегментов данных, при получении 
подтверждения на сегмент п — 8 отправитель может заключить, что сегмент п по- 
кинул сеть. 

Это иллюстрирует феномен самосинхронизации (self-clocking property) TCP- 
соединения в установившемся режиме [Jacobson 1988]. Полученный сегмент АСК 
служит сигналом для отправки следующего сегмента данных. 


п+7 п+6 п+5 п+4 п+3 п+2 п+1 n 


Данные Данные 


ACKs -— ACKs 


ACK АСК АСК АСК АСК АСК АСК ACK 
п-8 n-7 n-6 n-5 n-4 n-3 n-2 n-1 


Рис. 3.16. Сеть B установившемся режиме 


Примечание Этот механизм часто называют АСК-таймером (АСК clock). 


Если необходимо, чтобы механизм самосинхронизации работал и поддержи- 
вал трубу постоянно заполненной, то окно передачи должно быть достаточно ве- 
лико для обеспечения 16 неподтвержденных сегментов (от n — 8 дор + 7). Это озна- 
чает, что буфер передачи на вашей стороне и буфер приема на стороне получателя 
должны иметь соответствующий размер для хранения 16 сегментов. В общем слу- 
чае необходимо, чтобы в буфере помещалось столько сегментов, сколько находит- 
ся в заполненной трубе. Значит, размер буфера должен быть не меньше произве- 
дения полосы пропускания на задержку. 

Выше было отмечено, что это правило не особенно полезно. Причина в том, что 
обычно трудно узнать величину этого произведения. Предположим, что вы пишете 
приложение типа ЕТР. Насколько велики должны быть буферы приема и передачи? 
Во время написания программы неясно, какая сеть будет использоваться, а поэтому 
неизвестна и ее полоса пропускания. Но даже если это можно узнать во время выпол- 
нения, опросив сетевой интерфейс, то остается еще неизвестной величина задержки. 
В принципе, ее можно оценить с помощью какого-нибудь механизма типа ping, но, 
скорее всего, задержка будет варьироваться в течение существования соединения. 
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Прамечание Одно из возможных решений этой проблемы предложено в ра- 
боте [Semke et al.]. Оно состоит в динамическом изменении раз- 
меров буферов. Авторы замечают, что размер окна перегрузки 
можно рассматривать как оценку произведения полосы пропус- 
кания на задержку. Подбирая размеры буферов в соответствии 
с текущим размером окна перегрузки (конечно, применяя подхо- 
дящее демпфирование и ограничения, обеспечивающие справед- 
ливый режим для всех приложений), они сумели получить очень 
высокую производительность на одновременно установленных 
соединениях с разными величинами BWD. К сожалению, такое 
решение требует изменения в ядре операционной системы, так 
что прикладному программисту оно недоступно. 


Как правило, размер буферов назначают по величине, заданной по умолчанию 
или большей. Однако ни то, ни другое решение не оптимально. В первом случае 
может резко снизиться пропускная способность, во втором, как сказано в работе 
[Semke et al. 1998], — исчерпаны буферы, что приведет к сбою операционной cuc- 
темы. 

В отсутствии априорных знаний о среде, в которой будет работать приложе- 
ние, наверное, лучше всего использовать маленькие буферы для интерактивных 
приложений и буферы размером 32-64 Кб — для приложений, выполняющих MaC- 
совую передачу данных. Однако не забывайте, что при работе в высокоскоростных 
сетях следует задавать намного больший размер буфера, чтобы использовать всю 
доступную полосу пропускания. В работе [Mahdavi 1997] приводятся некоторые 
рекомендации по оптимизации настройки стеков TCP/IP. 

Есть одно правило, которое легко применять на практике, позволяющее по- 
высить общую производительность во многих реализациях. В работе [Сотег ап4 
Lin 1995] описывается эксперимент, в ходе которого два хоста были соединены 
сетью Ethernet в 10 Мбит и сетью АТМ в 100 Мбит. Когда использовался размер 
буфера 16 Кб, в одном и том же сеансе ЕТР была достигнута производительность 
1,313 Мбит/с для Ethernet и только 0,322 Мбит/с для АТМ. 

В ходе дальнейших исследований авторы обнаружили, что размер буфера, ве- 
личина МТО (максимальный размер передаваемого блока), максимальный размер 
сегмента ТСР (MSS) и способ передачи данных уровню ТСР от слоя сокетов вли- 
яли на взаимодействие алгоритма Нейгла и алгоритма отложенного подтвержде- 
ния (совет 24). 


Примечание MTU (максимальный блок передачи) — это максимальный размер 
фрейма, который может быть передан по физической сети. Для 
Ethernet эта величина составляет 1500 байт. Для сети АТМ, 
описанной в работе [Comer and Lin 1995], — 9188 байт. 


Хотя эти результаты были получены для локальной сети АТМ и конкретной 
реализации ТСР (SunOS 4.1.1), они применимы и к другим сетям и реализациям. 
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Самые важные параметры: величина МТО и способ обмена между сокетами 
и ТСР, который в большинстве реализаций, производных от ТСР один и тот же. 

Авторы нашли весьма элегантное решение проблемы. Его привлекательность 
в TOM, YTO изменять надо только размер буфера передачи, а размер буфера приема 
не играет роли. Описанное в работе [Comer and Lin 1995] взаимодействие не имеет 
места, если размер буфера передачи, по крайней мере, в три раза больше, чем MSS. 
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Примечание Смысл этого решения в том, что получателя вынуждают по- 
слать информацию об обновлении окна, а, значит, и АСК, предот- 
вращая тем самым откладывание подтверждения и нежелатель- 
ную интерференцию с алгоритмом Нейгла. Причины обновления 
информации о размере окна, различны для случаев, когда буфер 
приема меньше или больше утроенного MSS, но в любом случае 
обновление посылается. 


Поэтому неинтерактивные приложения всегда должны устанавливать буфер 
приема не менее чем 3 X MSS. Вспомните совет 7, где сказано, что это следует де- 
лать до вызова listen или connect. 


Резюме 


Производительность ТСР в значительной степени зависит от размеров буфе- 
ров приема и передачи (совет 36). В этом разделе вы узнали, что оптимальный раз- 
мер буфера для эффективной передачи больших объемов данных равен произведе- 
нию полосы пропускания на задержку, но на практике это наблюдение не особенно 
полезно. 

Хотя правило произведения применять трудно, есть другое, намного проще. 
Ему и рекомендуется всегда следовать: размер буфера передачи должен быть, по 
крайней мере, в три раза больше, чем MSS. 


Глава 4. Инструменты и ресурсы 


Совет 33. Используйте утилиту ping 


Один из самых главных и полезных инструментов отладки сетей и работаю- 
щих в них приложений - это утилита ping. Ее основное назначение — проверить 
наличие связи между двумя хостами. 

Прежде необходимо разъяснить несколько моментов, касающихся ping. Во-пер- 
вых, по словам Майка Myycca, слово «ping» He расшифровывается как «packet internet 
groper» (проводящий межсетевые пакеты). Своим названием эта программа обязана 
звуку, который издает сонар, устанавливаемый на подводных лодках. История созда- 
ния программы ping изложена в статье «The Story of the Ping Program» Муусса на 
ҰеЬ-странице http://ftp.arl.mil/-mike/ping/html. Там же приведен и ее исходный текст. 

Во-вторых, эта утилита не использует ни TCP, ни UDP, поэтому для нее нет 
никакого хорошо известного порта. Для проверки наличия связи ping пользуется 
функцией эхо-контроля, имеющейся в протоколе ICMP. Помните (совет 14), что, 
хотя сообщения [СМР передаются в ІР-датаграммах, [СМР считается не отдель- 
ным протоколом, а частью ТР. 


Примечание В КЕС 792 [Postel 1981] на первой странице сказано: «ICMP исполь- 
зует базовую поддержку IP, как если бы это был протокол более вы- 
сокого уровня, однако в действительности ІСМР является неотьем- 
лемой частью IP и должен быть реализован в каждом ІР-модуле». 


Таким образом, структура пакета, посылаемого ping, имеет такой вид, как на 
рис. 4.1. Показанная на рис. 4.2 ІСМР-часть сообщения состоит из восьмибайтно- 
го ІСМР-заголовка и п байт дополнительной информации. 


» Эхо-сообщение запрос/ответ 
для протокола ICMP 
20 байт 8+n байт 


Рис. 4.1. Формат пакета ping 


Обычно в качестве значения n — числа дополнительных байтов в пакете ping — 
выбирается 56 (UNIX) или 32 (Windows), но эту величину можно изменить C NO- 
мощью флагов -s (UNIX) или -1 (Windows). 

В некоторых версиях ping пользователь может задавать значения дополнитель- 
ных данных или даже указывать, что они должны генерироваться псевдослучайным 
образом. По умолчанию в большинстве версий дополнительные данные - это цик- 
лически переставляемый по кругу набор байтов. 
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Примечание Задание конкретных данных бывает полезно при отладке оши- 
бок, зависящих от данных. 


ОМГХ-версия ping помещает временной штамп (структуру timeval) в первые 
восемь байт дополнительных данных (при условии, конечно, что пользователь не 
задал меньшее количество). Когда программа ping получает эхо-ответ, она HCIIOJIb- 
зует этот временной штамп для вычисления периода кругового обращения (RTT). 
Windows-Bepcus ping этого не делает (вывод основан на анализе информации, по- 
лученной с помощью программы t cpdump), но в тексте примера ping, поставляемо- 
ro в составе компилятора Visual С++, этот алгоритм присутствует. 


0 78 15 16 31 


Тип Код 
Идентификатор Порядковый номер 


Дополнительные данные 


Рис. 4.2. Пакет эхо-сообщения запрос/ответ протокола ICMP 


Поскольку поля идентификатор и порядковый номер не задействованы ни 
в эхо-запросе, ни в эхо-ответе, ping использует их для идентификации получен- 
ных ІСМР-ответов. Так как для ІР-датаграмм нет специального порта, они достав- 
ляются каждому процессу, который открыл простой (raw) сокет с указанием про- 
токола ICMP (совет 40). Поэтому ping помещает свой идентификатор процесса в поле 
идентификатор, так что каждый запущенный экземпляр способен отличить отве- 
ты на свои запросы. Таким образом, поле идентификатор в этом случае можно 
представить как аналог номера порта. 

Таким же образом ping помещает в поле порядковый номер значение счетчика 
для того, чтобы связать ответ с запросом. Именно это значение ping показывает 
как icmp. seq. 

Обычно первое ваше действие при пропадании связи C удаленным XOCTOM — это 
запуск ping с указанием адреса этого хоста (хост «пингуется»). Предположим, что 
нужно связаться с хостом А с помощью программы telnet, но соединение не 
устанавливается из-за истечения тайм-аута. Причин может быть несколько: про- 
блема в сети между двумя хостами, не работает сам хост А, проблема в удаленном 
стеке TCP/IP или не запущен сервер telnet. 

Сначала следует проверить, «пингуя» хост А, что он достижим. Если работа 
ping проходит нормально, то можно сказать, что с сетью все в порядке, а проблема, 
вероятно, связана с самим хостом А. Если же невозможно «достучаться» до хоста А 
с помощью ping, то требуется «пропинговать» ближайший маршрутизатор, чтобы 
понять, удается ли достичь хотя бы границы собственной сети. Если это получается, 
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то воспользуйтесь программой traceroute (совет 35), чтобы выяснить, насколько 
далеко можно продвинуться по маршруту от вашего хоста к хосту А. Часто это 
помогает идентифицировать сбойный маршрутизатор или хотя бы сделать пред- 
положение о месте возникновения ошибки. 

Поскольку ping работает на уровне протокола ТР, она не зависит от правиль- 
ности конфигурации ТСР или UDP Поэтому иногда полезно «пропинговать» свой 
собственный хост, чтобы проверить правильность установки сетевого программ- 
ного обеспечения. Сначала можно указать ping возвратный адрес localhost 
(127.0.0.1), чтобы убедиться в работе хотя бы части сетевой поддержки. Если при 
этом проблем не возникает, то следует «пропинговать» один или несколько сете- 
вых интерфейсов и удостовериться, что они правильно сконфигурированы. 

Попробуйте «пропинговать» хост netcom4.netcom.com, который находится 
от вас в десяти переходах (рис. 4.3). 


bsd: $ ping netcom4.netcom.com 

PING netcom4.netcom.com (199.183.9.104): 56 data bytes 

64 bytes from 199.183.9.104: icmp seq-0 ttl1-245 time-598.554 ms 
64 bytes from 199.183.9.104: icmp seq-1 ttl-245 time-550.081 ms 
64 bytes from 199.183.9.104: icmp seq-2 ttl1-245 time-590.079 ms 
64 bytes from 199.183.9.104: icmp seq-3 ttl1-245 time-530.114 ms 
64 bytes from 199.183.9.104: icmp seq-5 tti-245 time-480.137 ms 
64 bytes from 199.183.9.104: icmp seq-6 ttl1-245 time-540.081 ms 
64 bytes from 199.183.9.104: icmp seq-7 ttl-245 time-580.084 ms 
64 bytes from 199.183.9.104: icmp seq-8 ttl1-245 Е1ме=490.078 ms 
64 bytes from 199.183.9.104: icmp seq-9 ttl1-2245 time-560.090 ms 
64 bytes from 199.183.9.104: icmp seq-10 ttl-245 time-490.090 ms 
^C завершили ping вручную 

— — — netcom4.netcom.com ping statistics — — — 

12 packets transmitted, 10 packets received, 16$ packet loss 
round-trip min/avg/max/stddev = 480.137/540.939/598.554/40.871 ms 
bsd: $ 


о LO XO LO LO XO XO XO MO iO 


Рис. 4.3. Короткий прогон ping 


Прежде всего, RTT для разных пакетов мало меняется и остается в пределах 
500 мс. Как следует из последней строки, RTT модифицируется в диапазоне от 
480,137 мс до 598,554 мс со стандартным отклонением 40,871 мс. Текст слишком 
рано прерван, чтобы можно было сделать какие-то выводы, но и при более дли- 
тельном прогоне (около 2 мин) результат существенно не изменится. Так что мож- 
но предположить, что нагрузка на сеть постоянная. Значительный разброс RTT — 
это, как правило, признак изменяющейся загрузки сети. При повышенной загруз- 
ке возрастает длина очереди B маршрутизаторе, а вместе с ней — и RTT. При 
уменьшении загрузки очередь сокращается, что приводит к уменьшению RTT. 

Далее из рис. 4.3 видно, что на эхо-запрос ICMP с порядковым номером 4 не при- 
шел ответ. Это означает, что запрос либо ответ был потерян одним из промежуточных 
маршрутизаторов. По данным сводной статистики, было послано 12 запросов (0—11) 
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и получено лишь 10 ответов. Один из пропавших ответов имеет порядковый 
номер 4, второй - 11 (вероятно, он был засчитан как пропавший, поскольку не во- 
время прервана работа ping). 


Резюме 


Утилита ping — это один из важнейших инструментов тестирования связи 
в сети. Поскольку для ее работы требуется лишь функционирование самых ниж- 
них уровней сетевых служб, она полезна для проверки связи в условиях, когда сер- 
висы более высокого уровня, такие как ТСР, или программы прикладного уровня 
типа telnet не работают. 

С помощью ping часто удается сделать выводы об условиях в сети, наблюдая 
за значениями и дисперсией RTT и за числом потерянных ответов. 


Совет 34. Используйте программу tcpdump 
или аналогичное средство 


Из всех имеющихся в нашем распоряжении мощных и полезных средств от- 
ладки сетевых приложений и поиска неисправностей в сети наиболее интересны 
сетевые анализаторы (их еще называют сниферами). Традиционно сетевой анали- 
затор — дорогое специализированное устройство, но современные рабочие станции 
вполне способны выполнять их функции в рамках отдельного процесса. 

Сегодня сниферы есть для большинства сетевых операционных систем. Ино- 
гда в операционную систему входит снифер, предлагаемый поставщиком (програм- 
ма snoop в Solaris или программы iptrace/ipreport в AIX), а иногда пользуются 
программами третьих фирм, например tcpdump. 

Из инструментов, предназначенных только для диагностики, сниферы постепен- 
но превратились в средства для исследований и обучения. Например, они постоянно 
используются для изучения динамики и взаимодействий в сетях. В книгах [Stevens 
1994, Stevens 1996] рассказано, как использовать tcpdump, чтобы разобраться в рабо- 
те сетевых протоколов. Наблюдая за данными, которые посылает протокол, вы може- 
те глубже понять его функционирование на практике, а заодно увидеть, когда некото- 
рая конкретная реализация работает не в соответствии со спецификацией. 

В этом разделе будет рассмотрена утилита tcpdump. Как уже отмечалось, есть 
и другие программно реализованные сетевые анализаторы. Некоторые из них луч- 
ше форматируют выходные данные, HO у tcpdump есть одно неоспоримое преиму- 
щество — она работает практически во всех ОМІХ-системах и в Windows. Поскольку 
исходные тексты tcpdump опубликованы, ее можно при необходимости адаптировать 
для специальных целей или перенести на новую платформу. 


Код tcpdump вы можете найти на сайте http://www-nrg.ee.lbl.gov/nrg.html, 


а исходные тексты и исполняемый код для Windows WinDump — http://netgroup- 
serv.polito.it/windump. 
Kak pa6oraer tcpdump 


Посмотрим, как работает программа t cpdump и на каком уровне протоколов она 
перехватывает пакеты. Как и большинство сетевых анализаторов, tcpdump состоит 
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из двух компонент: первая работает в ядре и занимается перехватом и, возможно, 
фильтрацией пакетов, а вторая действует в адресном пространстве пользователя 
и определяет интерфейс пользователя, а также выполняет форматирование и филь- 
трацию пакетов, если последнее не делается ядром. 

Пользовательская компонента tcpdump взаимодействует c компонентой B яд- 
pe при помощи библиотеки libpcap (библиотека для перехвата пакетов), кото- 
рая абстрагирует системно-зависимые детали общения с канальным уровнем сте- 
ка протоколов. Например, в системах на основе BSD libpcap взаимодействует 
c пакетным фильтром BSD (BSD packet filter - BPF) [McCanne and Jacobson 
1993]. ВРЕ исследует каждый пакет, проходящий через канальный уровень, и со- 
поставляет его с фильтром, заданным пользователем. Если пакет удовлетворяет 
критерию фильтрации, то его копия помещается в выделенный ядром буфер, ко- 
торый ассоциируется с данным фильтром. Когда буфер заполняется или истека- 
ет заданный пользователем тайм-аут, содержимое буфера передается приложению 
с помощью libpcap. 

Этот процесс изображен на рис. 4.4. Показано, как tcpdump и любая другая 
программа считывают необработанные пакеты с помощью ВРЕ атакже изображе- 
но еще одно приложение, читающее данные из стека TCP/IP как обычно. 


Примечание Хотя на этом рисунке и tcpdump, и программа используют 
библиотеку 11Ьрсар, можно напрямую общаться c ВРЕили иным 
интерфейсом, о чем будет сказано ниже. Достоинство 11bpcap 
в том, что она предоставляет системно-независимые средства 
доступа к необработанным пакетам. В настоящее время эта би- 
блиотека поддерживает BPF; интерфейс канального провайдера 
(data link provider interface — DLPI; систему SunOS МПТ; потоко- 
вую МТ; сокеты типа SOCK PACKET, применяемые в системе 
Linux; интерфейс snoop (IRIX) и разработанный в Стэнфорд- 
ском университете интерфейс enet. В дистрибутив WinDump 
входит также версия libpcap для Windows. 


Обратите внимание, что ВРЕ перехватывает сетевые пакеты на уровне драйвера 
устройства, то есть сразу после того, как они считаны с носителя. Это не то же самое, 
что чтение из простого сокета. В ситуации с простым сокетом вы получаете ІР-датаг- 
раммы, уже обработанные уровнем ГР и переданные непосредственно приложению, 
минуя транспортный уровень (ТСР или ОПР). Об этом рассказывается в совете 40. 

Начиная с версии 2.0, архитектура WinDump очень напоминает используемую 
в системах BSD. Эта программа пользуется специальным М”ІЅ-драйвером (NDIS - 
Network Driver Interface Specification — спецификация стандартного интерфейса 
сетевых адаптеров), предоставляющим совместимый c ВРЕ фильтр и интерфейс. 
В архитектуре WinDump МОГ$-драйвер фактически представляет собой часть сте- 
ка протоколов, но функционирует он так же, как показано на рис. 4.4, только надо 
заменить ВРЕ на пакетный драйвер NDIS. 
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Рис. 4.4. Перехват пакетов с помощью ВРЕ 


Другие операционные системы используют несколько иные механизмы. В сис- 
темах, производных OT SV КА, для доступа к простым сокетам применяется интер- 
фейс DLPI [Unix International 1991]. DLPI - это не зависящий от протокола, oc- 
нованный на системе STREAMS [Ritchie 1984] интерфейс к канальному уровню. 
С помощью DLPI можно напрямую получить доступ к канальному уровню, но 
по соображениям эффективности обычно вставляют в поток ЅТКЕАМ$-модули 
pfmod и bufmod. Модуль bufmod предоставляет услуги по буферизации сообще- 
ний и увеличивает эффективность за счет ограничения числа контекстных пере- 
ключений, требуемых для доставки данных. 


Примечание Это аналогично чтению полного буфера из сокета вместо по- 
байтного чтения. 


Модуль pfmod — это фильтр, аналогичный ВРЕ Поскольку он несовместим 
с фильтром BPF, tcpdump вставляет этот модуль в поток, а фильтрацию выполня- 
ет в пространстве пользователя. Это не столь эффективно, как при использовании 
ВРЕ так как в пространство пользователя приходится передавать каждый пакет, 
даже если он не нужен программе tcpdump. 
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На рис. 4.5 показаны tcpdump без модуля p £mod и приложение, которое получает 
необработанные пакеты с использованием находящегося в ядре фильтра. 

На рис. 4.5 также представлены приложения, пользующиеся библиотекой 
libpcap, но, как и в случае ВРЕ это необязательно. Для отправки сообщений непо- 
средственно в поток и получения их обратно можно было бы воспользоваться вызо- 
вами getmsg и putmsg. Книга [Rago 1993] – отличный источник информации o про- 
граммировании системы STREAMS, DLPI и системных вызовах getmsg и putmsg. 
Более краткое обсуждение вопроса можно найти в главе 33 книги [Stevens 1998]. 
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Рис. 4.5. Перехват пакетов с помощью DLPI 


Наконец, есть еще и архитектура Linux. В этой системе доступ к необработанным 
сетевым пакетам производится через интерфейс сокетов типа SOCK, PACKET. Для 
использования этого простого механизма надо открыть подобный сокет, при- 
вязать к нему требуемый сетевой интерфейс, включить режим пропускания всех 
пакетов (promiscuous mode) и читать из сокета. 


Примечание Начиная с версии 2.2 ядра Linux, рекомендуется несколько дру- 


гой интерфейс, но последняя версия 11bpcap по-прежнему под- 
держивает описанный выше. 
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Например, строка 
S = socket( AF. INET, SOCK PACKET, htons( ETH P ALL ) ); 


открывает сокет, предоставляющий доступ ко всем Еегпе-пакетам. В качестве 
третьего параметра можно также указать ЕТН_Р_ТР (пакеты ІР), ETH, P. IPV6 (па- 
кеты [Руб) или ETH, P. ARP (пакеты АКР). Будем считать, что этот интерфейс aHa- 
логичен простым сокетам (SOCK, RAW), только доступ производится к канальному, 
а не сетевому (ТР) уровню. 

К сожалению, несмотря на простоту и удобство этого интерфейса, он не очень 
эффективен. В отличие от обычных сокетов, ядро в этом случае не осуществляет 
никакой буферизации, так что каждый пакет доставляется приложением сразу 
после поступления. Отсутствует также фильтрация на уровне ядра (если не счи- 
тать параметра ЕТН_Р_*). Поэтому фильтровать приходится на прикладном уров- 
не, а это означает, что приложение должно получать все пакеты без исключения. 


Использование tcpdump 


Прежде всего для использования tcpdump надо получить разрешение. Посколь- 
ку применение сетевых анализаторов небезопасно, по умолчанию tcpdump KOH- 
фигурируется с полномочиями суперпользователя root. 


Примечание К системе Windows это не относится. Коль скоро МОГ5-драй- 
вер для перехвата пакетов установлен, воспользоваться про- 
граммой WinDump может любой. 


Во многих случаях лучше дать возможность всем пользователям работать 
с программой t cpdump, не передавая им полномочия суперпользователя. Это де- 
лается по-разному, в зависимости от версии UNIX и документировано в руковод- 
стве по tcpdump. В большинстве случаев надо либо предоставить всем права на 
чтение из сетевого интерфейса, либо сделать tcpdump зейи!4-программой. 

Проще всего вызвать tcpdump вообще без параметров. Тогда она будет nepe- 
хватывать все сетевые пакеты и выводить о них информацию. Однако полезнее 
указать какой-нибудь фильтр, чтобы видеть только нужные пакеты и не отвле- 
каться на остальные. Например, если требуются лишь пакеты, полученные от хо- 
ста bsd или отправленные ему, то можно вызвать tcpdump так: 


tcpdump host bsd 


Если же нужны пакеты, которыми обмениваются хосты bsd и sparc, TO мож- 
но использовать такой фильтр: 


host bsd and host sparc 
ИЛИ сокращенно — 
host bsd and sparc 


Язык для задания фильтров достаточно богат и позволяет фильтровать, Ha- 
пример, по следующим атрибутам: 
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о протокол; 

О хост отправления и/или назначения; 

о сеть отправления и/или назначения; 

о Ефегпе-адрес отправления и/или назначения; 

О порт отправления и/или назначения; 

о размер пакета; 

о пакеты, вещаемые на всю локальную сеть или на группу (как в Ethernet, так 
u B IP); 

О пакет, используемый в качестве шлюза указанным XOCTOM. 


Кроме того, можно проверять конкретные биты или байты в заголовках про- 
токолов. Например, чтобы отбирать только ТСР-сегменты, в которых выставлен 
бит срочных данных, следует использовать фильтр 


tcp[ 13 ] & 16 


Чтобы понять последний пример, надо знать, что четвертый бит четырнадца- 
того байта заголовка ТСР - это бит срочности. 

Поскольку разрешается использовать булевские операторы and (или &&), or 
(или 11) u not (или !) для комбинирования простых предикатов, можно задавать 
фильтры произвольной сложности. Ниже приведен пример фильтра, отбирающе- 
ro ІСМР-пакеты, приходящие из внешней сети: 


icmp and not src net locainet 


Примеры более сложных фильтров рассматриваются в документации по t cpdump. 


Выходная информация, формируемая tcpdump 


Информация, выдаваемая программой tcpdump, зависит от протокола. Pac- 
смотрим несколько примеров, которые помогут составить представление о том, 
что можно получить OT tcpdump для наиболее распространенных протоколов. До- 
кументация, поставляемая вместе с программой, содержит исчерпывающие све- 
дения о формате выдачи. 

Первый пример - это трассировка сеанса по протоколу SMTP (Simple Май Trans- 
fer Protocol — простой протокол электронной почты), то есть процедура отправки элек- 
тронного письма. Распечатка на рис. 4.6 в точности соответствует выдаче tcpdump — 
только добавлены номера строк, напечатанные курсивом, удалено имя домена хос- 
та bsd и перенесены длинные строки, He уместившиеся на странице. 

Для получения трассировки послано письмо пользователю с адресом в домене 
gte.net. Таким образом, адрес имел вид userGgte.net. 

Строки 1—4 относятся к поиску адреса SMTP-cepBepa, обслуживающего домен 
gte.net. Это пример выдачи, генерируемой tcpdump для запросов и ответов Cep- 
виса DNS. В строке 1 bsd запрашивает у сервера имен своего сервис-провайдер 
(nsl.ix.netcom.com) имя или имена почтового сервера gte.net. В первом поле 
находится временной штамп пакета (12:54:32.920881). Поскольку разрешающая 
способность таймера на машине bsd составляет 1 мкс, показано шесть десятичных 
знаков. Вы видите, что пакет ушел из порта 1067 на рза в порт 53 (domain) на ма- 
шине ns1. Далее, дается информация о данных в пакете. Первое поле (45801) – 
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1 12: 


2 12: 


3 12: 


4 12: 


5 12: 


[^v] 
m 
№ 


24 12: 


25 12: 


26 12: 


27 12: 


28 12: 


54:32.920881 bsd.1067 > nsl.ix.netcom.com.domain: 
45801+ MX? gte.net. (25) 

54:33.254981 nsl.ix.netcom.com.domain > bsd.1067: 
45801 5/4/9 (371) (DF) 

54:33.256127 bsd.1068 > nsl.ix.netcom.com.domain: 
45802+ A? mtapop2.gte.net. (33) 

54:33.534962 nsl.ix.netcom.com.domain > bsd.1068: 
45802 1/4/4 (202) (DF) 

54:33.535737 bsd.1059 » mtapop2.gte.net.smtp: 

S 585494507:585494507(0) win 16384 

«mss 1460,nop,wscale 0,nop,nop, 

timestamp 6112 0» (DF) 


:54:33.784963 mtapop2.gte.net.smtp > bsd.1059: 


S 1257159392:1257159392(0) ack 585494509 win 49152 
«mss 1460,nop,wscale 0,nop,nop, 
timestamp 7853753 6112» (DF) 


:54:33.785012 bsd.1059 » mtapop2.gte.net.smtp: 


ack 1 win 17376 «nop,nop, 
timestamp 6112 7853753» (DF) 


:54:34.235066 mtapop2.gte.net.smtp » bsd.1059: 


P 1:109(108) ack 1 win 49152 
«nop,nop,timestamp 7853754 6112» (DF) 


:54:34.235277 bsd.1059 » mtapop2.gte.net.smtp: 


P 1:19(18) ack 109 win 17376 

«nop,nop,timestamp 6113 7853754» (DF) 

14 строк опущено 

54:36.675105 bsd.1059 > mtapop2.gte.net.smtp: 

Е 663:663 (0) ack 486 win 17376 

«nop,nop,timestamp 6118 7853758» (DF) 

54:36.685080 mtapop2.gte.net.smtp » bsd.1059: 

F 486:486(0) ack 663 win 49152 

«nop,nop,timestamp 7853758 6117» (DF) 

54:36.685126 bsd.1059 » mtapop2.gte.net.smtp: 
ack 487 win 17376 

«nop,nop,timestamp 6118 7853758» (DF) 

54:36.934985 mtapop2.gte.net.smtp » bsd.1059: 

F 486:486(0) ack 664 win 49152 

«nop,nop,timestamp 7853759 6118» (DF) 

54:36.935020 bsd.1059 » mtapop2.gte.net.smtp: 
ack 487 win 17376 

«nop,nop,timestamp 6118 7853759» (DF) 


Рис. 4.6. Трассировка ЗМТР-сеанса с включением обмена no протоколам DNS и ТСР 


это номер 


запроса, используемый функциями разрешения имен на bsd для сопо- 


ставления ответов с запросами. Знак «+» означает, что функция разрешения задает 
опрос DNS-cepBepoM других серверов, если y него нет информации об ответе. Стро- 


ка «МХ?» 


показывает, что это запрос о записи почтового обмена для сети, имя ко- 


торой стоит в следующем поле (gte.net). Строка «(25)» свидетельствует о TOM, 
что длина запроса — 25 байт. 
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Строка 2 - это ответ на запрос в строке 1. Число 45801 - это номер sanpo- 
са, к которому относится ответ. Следующие три поля, разделенные косой чер- 
той, — количество записей в ответе, записей от сервера имен (полномочного аген- 
та) и прочих записей. Строка «(371)» показывает, что ответ содержит 371 байт. 
И, наконец, строка «(DF)» означает, что в [Р-заголовке ответа был поднят бит 
«Don't fragment» (не фрагментировать). Итак, эти две строки иллюстрируют ис- 
пользование системы DNS для поиска обработчиков почты (06 этом кратко упо- 
миналось в совете 29). 

Если в двух первых строках было выяснено имя обработчика почты для сети 
gte.net, TO в двух последующих выясняется егоПрограмма tcpdump [Р-адрес. 
«А?» в строке З указывает, что это запрос ІР-адреса хоста mtapop2.gte.net- од- 
ного из почтовых серверов компании СТЕ. 

Строки 5-28 содержат детали обмена по протоколу SMTP. Процедура трех- 
стороннего квитирования между хостами bsd и mtapop2 начинается в строке 5 
и заканчивается строкой 7. Первое поле после временного штампа и имен хостов — 
это поле flags. «S» в строке 5 указывает, что в сегменте установлен флаг SYN. 
Другие возможные значения флага: «Е» (FIN), «О» (URG), «P» (PUSH), «К» 
(RST) и <.> (нет флагов). Далее идут порядковые номера первого и последнего 
байтов, а за ними в скобках — число байтов данных. Эти поля могут вызвать неко- 
торое недоумение, так как «порядковый номер последнего» — это первый неис- 
пользованный порядковый номер, но только в том случае, когда в пакете есть 
данные. Удобнее всего считать, что первое число — это порядковый номер пер- 
вого байта в сегменте (SYN или информационном), а второе – порядковый номер 
первого байта плюс число байтов данных в сегменте. Следует отметить, что по 
умолчанию показываются реальные порядковые номера для SYN-cerMeHTOB и сме- 
щения — для последующих сегментов (так удобнее следить). Это поведение мож- 
но изменить с помощью опции -S в командной строке. 

Во всех сегментах, кроме первого ЗУМ, имеется поле АСК, показывающее, 
какой следующий порядковый номер ожидает отправитель. Это поле (в виде ack 
nnn), как и раньше, по умолчанию содержит смещение относительно порядкового 
номера, указанного в сегменте SYN. 

За полем АСК идет поле window. Это количество байтов данных, которое го- 
тов принять удаленный хост. Обычно оно отражает объем свободной памяти в бу- 
ферах соединения. 

И, наконец, в угловых скобках указаны опции ТСР. Основные опции рассмат- 
риваются в КЕС 793 [Postel 19815] и ВЕС 1323 [Jacobson et al. 1992]. Они обсуж- 
даются также в книге [Stevens 1994], а их полный перечень можно найти на Web- 
странице http;//www.isi,edu/in-notes/iana/assignments/tcp-parameters. 

В строках 8-23 показан диалог между программой sendmail на bsd и SMTP- 
сервером Ha машине mtapop2. Большая часть этих строк опущена. Строки 24-28 
отражают процедуру разрыва соединения. Сначала bsd посылает FIN в строке 24, 
затем приходит FIN or mtapop2 (строка 25). Заметьте, что в строке 27 mtapop2 
повторно посылает FIN. Это говорит о том, что хост не получил OT bsd подтвержде- 
ния АСК на свой первый FIN, иеще раз подчеркивает важность состояния TIME- 
WAIT (совет 22). 
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Теперь посмотрим, что происходит при обмене ОРЮР-датаграммами. C помо- 
щью клиента udphelloc (совет 4) следует послать один нулевой байт в порт cep- 
вера времени дня в домене netcom. сом: 


bsd: $ udphelloc netcom4.netcom.com daytime 
Thu Sep 16 15:11:49 1999 
bsd: $ 


Хост netcom4 возвращает дату и время B U DP-nararpamme. Программа tcpdump 
печатает следующее: 


18:12:23.130009 bsd.1127 > nectom4.netcom.com.daytime: udp 1 
18:12:23.389284 nectom4.netcom.com.daytime > bsd.1127: udp 26 


Отсюда видно, что bsd послал net com4 ОПР-датаграмму длиной один байт, 
a netcom4 ответил датаграммой длиной 26 байт. 

Протокол обмена ІСМР-пакетами аналогичен. Ниже приведена трассировка 
одного запроса, генерируемого программой ping с хоста bsd на хост netcom4: 


1 06:21:28.690390 bsd > netcom4á.netcom.com: icmp: echo request 
2 06:21:29.400433 netcom4d.netcom.com > bsd: icmp: echo reply 


Строка icmp: означает, что это ІСМР-датаграмма, a следующий за ней текст 
описывает тип этой датаграммы. 

Один из недостатков tcpdump — это неполная поддержка вывода собственно 
данных. Часто во время отладки сетевых приложений необходимо знать, какие 
данные посылаются. Эту информацию можно получить, задав в командной строке 
опции -S и -х, но данные будут выведены только B шестнадцатеричном формате. 
Опция -х показывает, что содержимое пакета нужно выводить в шестнадцатерич- 
ном виде. Опция -з сообщает, сколько данных из пакета выводить. По умолчанию 
tcpdump выводит только первые 68 байт (в системе SunOS МТ - 96 байт). Этого 
достаточно для заголовков большинства протоколов. Повторим предыдущий при- 
мер, касающийся UDP, но здесь нужно выводить также следующие данные: 


tcpdump -х -s 100 -1 


После удаления строк, относящихся к DNS, и исключения имени домена из 
адреса хоста bsd получается следующий результат: 


1 12:57:53.299924 bsd.1053 > netcom4.netcom.com.daytime: udp 1 
4500 001d 03d4 0000 4011 17a1 c7b7 c684 
c7b7 0968 041а 000d 0009 9c56 00 

2 12:57:53.558921 netcom4d.netcom.com.daytime > bsd.1053: udp 26 
4500 0036 f0c8 0000 3611 3493 c7b7 0968 
c7b7 c684 000а 041d 0022 765a 5375 6е20 
5365 7020 3139 2030 393a 3537 3a34 3220 
3139 3939 Qad 


Последний байт B первом пакете — это нулевой байт, который udphelloc посы- 
лает хосту net com4. Последние 26 байт второго пакета — это полученный ответ. MH- 
терпретировать приведенные в нем шестнадцатеричные цифры довольно трудно. 
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Авторы tcpdump не хотели давать АЗСП-представление данных, так как 
полагали, что это упростит кражу паролей для технически неподготовленных 
лиц. Теперь многие считают, что широкое распространение программ для кра- 
жи паролей сделало это опасение неактуальным. Поэтому есть основания по- 
лагать, что в последующие версии tcpdump будет включена поддержка вывода 
в коде ASCII*. 

А пока многие сетевые программисты упражняются в написании фильтров, 
преобразующих выдачу tcpdump в код ASCII. Несколько подобных программ есть 
в Internet. Показанный в листинге 4.1 сценарий Perl запускает tcpdump, перена- 
правляет ее вывод к себе и перекодирует данные в ASCII. 


Листинг 4. 1. Рей-сценарий для фильтрации выдачи tcpdump 


tcpd 

1 4$! /usr/bin/per15 

2 Stcpdump = "/usr/sbin/tcpdump"; 

3 open( TCPD, "$tcpdump QGARGV |" ) || 

4 die "He могу запустить tcpdump: \$!\\п"; 

5 $1 = 1; 

6 while ( «TCPD» ) 

TEL 

8 LE АЕ У) 

9 { 

10 chop; 
11 $str = $.; 

12 $str =~ tr / Nt//d; 

13 Sstr = pack "H*" , $str; 

14 S$str =~ tr/\x0-\x1f\x7f-\xff/./; 

15 printf "WXtg-40sNt$sWMn", substr( $., 4 ), $str; 
16 } 

17 else 

18 ( 

19 print; 
20 } 

21 } 

вера 


Если еще раз прогнать последний пример, но вместо tcpdump использовать 
t Cpd, то получится следующее: 


1 12:58:56.428052 bsd.1056 > netcom4.netcom.com.daytime: udp 1 
4500 001d 0347 0000 4011 179e c7b7 c684 E....... raus 
C7b7 0968 041d 000d 0009 9c56 00 ...h. ..... S. 

2 12:58:56.717128 netcom4.netcom.com.daytime > bsd.1053: udp 26 
4500 0036 10f1 0000 3611 146b c7b7 0968 E..6....6..k...h 


C7b7 c684 000а 0420 0022 7656 5375 6e20 ....... ."rVSun 
5365 7020 3139 2030 393a 3538 3a34 3620 Sep 19 09:58:46 
3139 3939 0a0d 1999.. 


* Начиная c версии 3.5 tcpdump позволяет выводить и АЗСП-представление. Для этого надо одновре- 
менно указать опции -X и -x — Прим. автора. 
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Резюме 


Программа tcpdump - это незаменимый инструмент для изучения того, что про- 
исходит в сети. Если знать, что в действительности посылается или принимается «по 
проводам», то трудные, на первый взгляд, ошибки удается легко найти и исправить. 
Эта программа представляет собой также важный инструмент для исследований 
динамики сети, а равно средство обучения. В последнем качестве она широко при- 
меняется в книгах серии «TCP/IP Illustrated», написанных Стивенсом. 


Совет 35. Применяйте программу traceroute 


Утилита traceroute - это важный инструмент для нахождения ошибок марш- 
рутизации, изучения трафика B Internet и исследования топологии сети. Как и мно- 
гие другие распространенные сетевые инструменты, traceroute была разработана 
коллективом лаборатории Лоренса Беркли в Университете Калифорнии. 


Примечание В комментариях к исходному тексту Ван Джекобсон, автор npo- 
граммы traceroute, пишет: «Я пытался найти ошибку в рабо- 
те алгоритма маршрутизации в течение 48 бессонных часов, 
и этот код родился как-то сам собой». 


Идея traceroute проста. Программа пытается определить маршрут между 
двумя хостами в сети, заставляя каждый промежуточный маршрутизатор посы- 
лать [СМР-сообщение об ошибке хосту-отправителю. Далее об этом механизме 
будет сказано подробнее. Сначала нужно несколько раз запустить программу и по- 
смотреть, что она выдает. Проследим маршрут между хостом bsd и компьютером 
в Университете города Тампа на юге Флориды (рис. 4.7). Как обычно, перенесены 
строки, He умещающиеся на странице. 

Число слева в каждой строке — это номер промежуточного узла. За ним идет 
имя хоста или маршрутизатора в этом узле и далее – [Р-адрес узла. Если узнать 
имя не удается, то traceroute печатает только ІР-адрес. Такая ситуация наблю- 
дается в узле 13. Как видно, по умолчанию программа пыталась определить имя 
хоста или маршрутизатора трижды, а три числа, следующие за 1Р-адресом, – это 
периоды кругового обращения (RTT) для каждой из трех попыток. Если при oue- 
редной попытке на запрос никто не отвечает или ответ теряется, то вместо време- 
ни печатается «*», 

Хотя компьютер ziggy.usf.edu расположен в соседнем городе, B Internet 
между ними находится 14 узлов. Сначала данные проходят через два маршрутиза- 
тора в Тампе, относящихся к сети net com. net (это сервис-провайдер, через которого 
bsd выходит B Internet), потом еще Через два маршрутизатора, а затем через марш- 
рутизатор netcom.net вузле MAE-EAST (узел 5) в сеть, находящуюся в Вашинг- 
тоне, округ Колумбия. Узел МАЕ-ЕАЗТ - это точка пересечения сетей, в которой сер- 
вис-провайдеры передают друг другу Іпќегпеї-трафик. Далее покидает узел MAE-EAST 
и попадает в сеть sprintlink.net. От маршрутизатора сети Sprintlink в узле 
MAE-EAST он пролегает вдоль восточного побережья до домена us Е . edu (узел 13). 
И наконец на шаге 14 маршрут подходит к компьютеру Ziggy. 
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bsd: $ traceroute ziggy. usf. edu 
traceroute to ziggy. usf. edu (131. 247. 1. 40), 30 hops max, 
40 byte packets 
1 tam-fl-pm8. netcom. net (163. 179. 44. 15) 
128. 960 ms 139. 230 ms 129. 483 ms 
2 tam-fl-gwl1. netcom. net (163. 179. 44. 254) 
139. 436 ms 129.226 ms 129.570 ms 
3 hl-0.mig-fl-gwl.netcom.net (165.236.144.110) 
279.582 ms 199.325 ms 289.611 ms 
4 ab-0-0-7.was-dc-gwl.netcom.net (163.179.235.121) 
179.505 ms 229.543 ms 179.422 ms 
5 hl-0.mae-east.netcom.net (163.179.220.182) 
189.258 ms 179.211 ms 169.605 ms 
6 sl-mae-e-f0-0.sprintlink.net (192.41.177.241) 
189.999 ms 179.399 ms 189.472 ms 
7 sl-bb4-dc-1-0-0.sprintlink.net (144.228.10.41) 
180.048 ms 179.388 ms 179.562 ms 
8 sl-bblO0-rly-2-3.sprintlink.net (144.232.7.153) 
199.433 ms 179.390 ms 179.468 ms 
9 sl-bbll-rly-9-O0.sprintlink.net (144.232.0.46) 
199.259 ms 189.315 ms 179.459 ms 
10 sl-bblO0-orl-1-0.sprintlink.net (144.232.9.62) 
189.987 ms 199.508 ms 219.252 ms 
11 sl-gw3-orl-4-0-0.sprintlink.net (144.232.2.154) 
219.307 ms 209.382 ms 209.502 ms 
12 sl-usf-1-0-0.sprintlink.net (144.232.154.14) 
209.518 ms 199.288 ms 219.495 ms 
13 131.247.254.36 (131.247.254.36) 209.318ms 199.281ms 219.588ms 
14 ziggy.usf.edu (131.247.1.40) 209.591 ms * 210.159 ms 


Рис. 4.7. Маршрут до хоста ziggy.usf.edu, прослеженный traceroute 


Посмотрим, как далеко от bsd отстоит Калифорнийский университет в Лос- 
Анджелесе. Понятно, что географически он находится на другом конце страны, 
в Калифорнии. А если выполнить traceroute до хоста panther в Калифорний- 
ском университете, то получится результат, показанный на рис. 4.8. 

На этот раз маршрут проходит только через 13 промежуточных узлов и дости- 
raer домена ucla.edu на шаге 11. Таким образом, топологически bsd ближе к Ka- 
лифорнийскому университету, чем к Университету на юге Флориды. 


Примечание Университет Чепмена, расположенный также вблизи Лос-Анд- 
желеса, находится всего в девяти промежуточных шагах от 
Ьза. Это связано с тем, что домен chapman. edu, как и bsd, под- 
ключен к Internet uepea сеть netcom.net, и весь трафик проходит 
по этой опорной сети. 


Как работает traceroute 


А теперь разберемся, как работает traceroute. Вспомним (совет 22), что в IP- 
датаграмме есть поле TTL, которое уменьшается наединицу каждым промежуточным 
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bsd: $ traceroute panther.c8.ucla.edu 
traceroute to panther.cs-ucia.edu (131.179.128.25), 
30 hops max, 40 byte packets 
1 tam-fl-pm8.netcom.net (163.179.44.15) 
148.957 ms 129.049 ms 129.585 ms 
2 tam-fl-gwl.netcom.net (163.179.44.254) 
139.435 ms 139.258 ms 139.434 ms 
3 hl-0.mig-fl-gwl.netcom.net (165.236.144.110) 
139.538 ms 149.202 ms 139.488 ms 
4 a5-0-0-7.was-dc-gwl.netcom.net (163.179.235.121) 
189.535 ms 179.496 ms 168.699 ms 
5 h2-0.mae-east.netcom.net (163.179.136.10) 
180.040 ms 189.308 ms 169.479 ms 
6 cpe3-fddi-0.Washington.cw.net (192.41.177.180) 
179.186 ms 179.368 ms 179.631 ms 
7 coreb5b-hssi6-0-0.Washington.cw.net (204.70.1.21) 
199.268 ms 179.537 ms 189.694 ms 
8 corerouter2.Bloomington.cw.net (204.70.9.148) 
239.441 ms 239.560 ms 239.417 ms 
9 bordercore3.Bloomington.cw.net (166.48.180.1) 
239.322 ms 239.348 ms 249.302 ms 
10 ucla-internet-t-3.Bloomington.cw.net (166.48.181.254) 
249.989 ms 249.384 ms 249.662 ms 
11 cbn5-t3-l.cbn.ucla.edu (169.232.1.34) 
258.756 ms 259.370 ms 249.487 ms 
12 131.179.9.6 (131.179.9.6) 249.457 ms 259.238 ms 249.666 ms 
13 Panther.CS.UCLA.EDU (131.179.128.25) 259.256 ms 259.184 ms * 
bsd: $ 


Рис. 4.8. Маршрут до хоста panther.cs.ucla.edu, прослеженный traceroute 


маршрутизатором. Когда маршрутизатор получает датаграмму, у которой в поле 
TTL находится единица (или нуль), он отбрасывает ее и посылает отправителю 
[СМР-сообщение «истекло время в пути». 

Программа traceroute использует это свойство. Сначала она посылает по- 
лучателю UDP-zararpaMMy, в которой TTL установлено в единицу. Когда дата- 
грамма доходит до первого маршрутизатора, тот определяет, что поле TTL равно 
единице, отбрасывает датаграмму и посылает отправителю ІСМР-сообщение. 
Так вы узнаете адрес первого промежуточного узла (из поля «адрес отправите- 
ля» в заголовке ICMP). И traceroute пытается выяснить его имя с помощью 
функции gethostbyaddr. Чтобы получить информацию о втором узле, traceroute 
повторяет процедуру, на этот раз установив TTL равным двум. Маршрутизатор 
в первом промежуточном узле уменьшит TTL на единицу и отправит датаграмму 
дальше. Но второй маршрутизатор определит единицу в поле TTL, отбросит да- 
таграмму и пошлет ІСМР-сообщение отправителю. Повторяя эти действия, но уве- 
личивая каждый раз значение TTL, traceroute может построить весь маршрут 
от отправителя к получателю. 
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Рис. 4.9. Маршрутизатор N ошибочно переправляет 
датаграмму с TTL, равным нулю 


Когда датаграмма с достаточно большим начальным значением TTL наконец 
доходит до получателя, TTL будет равно единице, но, поскольку дальше пере- 
правлять датаграмму некуда, стек TCP/IP попытается доставить ее ожидающему 
приложению. Однако traceroute установлено в качестве порта назначения Ta- 
кое значение, которое вряд ли кем-то используется, поэтому хост-получатель вер- 
нет ІСМР-сообщение «порт недоступен». Получив такое сообщение, tracerout 
определяет, что конечный получатель обнаружен, и трассировку можно завершить. 

Поскольку протокол UDP ненадежен (совет 1), не исключена возможность по- 
тери датаграмм. Поэтому traceroute пытается «достучаться» до каждого проме- 
жуточного хоста или маршрутизатора несколько раз, то есть посылает несколько 
датаграмм с одним и тем же значением ТТГ. По умолчанию делается три попыт- 
ки, но это можно изменить с помощью опции -q. 

Кроме того, tracerout нужно определить, сколько времени ждать ICMP-co- 
общения после каждой попытки. По умолчанию время ожидания - 5 с, но это зна- 
чение можно изменить с помощью опции -и. Если в течение этого времени ICMP- 
сообщение не получено, то вместо значения RTT печатается звездочка (*). 

В описанном процессе могут быть некоторые трудности: traceroute полагается 
Ha TO, что маршрутизаторы будут, как положено, отбрасывать ІР-датаграммы, B KO- 
торых TTL равно единице, и посылать при этом ІСМР-сообщение «истекло время 
в пути». К сожалению, некоторые маршрутизаторы таких сообщений не посылают, 
и тогда печатаются звездочки. Есть также маршрутизаторы, которые посылают со- 
общение, но с тем значением ТТТ, которое обнаружили во входящей датаграмме. 
Поскольку оно оказалось равным нулю, то датаграмма будет отброшена первым же 
узлом на обратном пути (если, конечно, это не случилось на первом шаге). Результат 
точно такой же, как если бы ІСМР-сообщение не посылалось вовсе. 

Некоторые маршрутизаторы ошибочно переправляют далее датаграммы, в ко- 
торых TTL равно нулю. Если такое происходит, то следующий маршрутизатор, 
например М + 1, отбросит датаграмму и вернет ІСМР-сообщение «истекло время 
в пути». На дальнейшей итерации маршрутизатор М + 1 получит датаграмму со 
значением TTL, равным единице, и вернет обычное {СМР-сообщение. Таким 
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образом, маршрутизатор М + 1 появится дважды: первый раз в результате ошибки 
предыдущего маршрутизатора, а второй — после корректного отбрасывания дата- 
граммы с истекшим временем работы. Такая ситуация изображена на рис. 4.9, а ее 
видимое проявление - в строках, соответствующих узлам 5 и б на рис. 4.10. 


bsd: $ traceroute syrup.hill.com 
traceroute to syrup.hill.corn (208.162.106.3), 
30 hops max, 40 byte packets 
1 tam-fl-pm5.netcom.net (163.179.44.11) 
129.120 ms 139.263 ms 129.603 ms 
2 . tam-fl-gwl.netcom.net (163.179.44.254) 
129.584 ms 129.328 ms 149.578 ms 
3 hl-0O.mig-fl-gwl.netcom.net (165.236.144.110) 
219.595 ms 229.306 ms 209.602 ms 
4 a5-0-0-7.was-dc-gwl.netcom.net (163.179.235.121) 
179.248 ms 179.521 ms 179.694 ms 
5  h2-0.mae-east.netcom.net (163.179.136.10) 
179.274 ms 179.325 ms 179.623 ms 
6 h2-0.mae-east.netcom.net (163.179.136.10) 
169.443 ms 199.318 ms 179.601 ms 
7  cpe3-fddi-O.washington.cw.net (192.41.177.180) 189.529 ms 
core6-serial5-1-0.Washington.cw.net 
(204.70.1.221) 209.496 ms 209.247 ms 
8  bordercore2.Boston.cw.net (166.48.64.1) 
209.486 ms 209.332 ms 209.598 ms 
9 hill-associatesinc-internet.Boston.cw.net (166.48.67.54) 
229.602 ms 219.510 ms * 
10 syrup.hill.corn (208.162.106.3) 239.744 ms 239.348 m 219.607 ms 
bsd: $ 


Рис. 4.10. Выдача traceroute c повторяющимися узлами 


На рис. 4.10 показано еще одно интересное явление. Вы видите, что в узле 7 
маршрут изменился после первой попытки. Возможно, это было вызвано тем, что 
маршрутизатор в узле 6 выполнил какие-то действия по балансированию нагрузки. 
А возможно, что узел cpe3-fddi-0.washington.cw.net за время, прошедшее 
с момента первой попытки, успел «отключиться», и вместо него был использован 
маршрутизатор с адресом core6-serial5-1-0.Washington.cw.net. 

Еще одна проблема, встречающаяся, к сожалению, все чаще, состоит в том, что 
маршрутизаторы полностью блокируют все ІСМР-сообщения. Некоторые органи- 
зации, ошибочно полагая, что ІСМР-сообщения несут какую-то опасность, отключа- 
ют их. В таких условиях traceroute становится бесполезной, поскольку первый же 
такой узел, встретившийся на маршруте к получателю, с точки зрения traceroute 
ведет себя как «черная дыра». Никакая информация от последующих узлов не до- 
ходит, так как этот маршрутизатор отбрасывает и сообщение «истекло время 
в пути», и сообщение «порт недоступен». 

Следующая проблема при работе с traceroute — это асимметрия маршрутов. 
Запуская traceroute, вы получаете маршрут от пункта отправления до пункта 
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назначения, но нет гарантии, что датаграмма, отправленная из пункта назначения, 
будет следовать тем же маршрутом. Хотя кажется естественным предположение 
о том, что почти все маршруты одинаковы, в действительности, как показано в ра- 
боте [Paxson 1997], 49% изученных маршрутов демонстрируют асимметрию хотя 
бы в одном промежуточном узле. 


Примечание С помощью опции -s, которая устанавливает режим свободной 
маршрутизации, заданной источником (loose source routing) от 
пункта назначения в пункт отправления, теоретически можно 
получить оба маршрута. Но, как отмечает Джекобсон в ком- 
ментариях к исходному тексту traceroute, количество мар- 
шрутизаторов, которые некорректно выполняют маршрутиза- 
цию, заданную источником, настолько велико, что этот метод на 
практике не работает. В главе 8 книги [Stevens 1994] объясняется 
суть метода и приводится пример его успешного применения. 


В другой работе Паксон отмечает, что асимметричные маршруты возникают 
также из-за эффекта «горячей картофелины» [Рахзоп 1995]. 


Примечание Этот эффект состоит в следующем. Предположим, что хост А, 
расположенный на восточном побережье Соединенных Штатов, 
отправляет датаграмму хосту В на западном побережье. 
Хост А подключен x Internet через провайдера 1, а хост В — 
через провайдера 2. Допустим, что у обоих провайдеров есть 
опорные сети, проходящие через всю страну. Поскольку полоса 
пропускания опорной сети — это дефицитный ресурс, провай- 
дер 1 пытается доставить датаграмму хосту в сети провай- 
дера 2, пользуясь его же опорной сетью. Но точно так же, когда 
хост В отвечает, провайдер 2 пытается доставить ответ на 
противоположное побережье, пользуясь опорной сетью провай- 
дера 1. Отсюда и асимметрия. 


Программа tracert в системе Windows 


До сих пор описывалась UNIX-Bepcus программы traceroute. Очень noxo- 
жее средство — tracert — есть и в различных версиях операционной системы 
Windows. Программа tracert работает аналогично traceroute, но для опреде- 
ления маршрута используются He ОЮР-датаграммы, а эхо-запросы протокола 
ICMP (как в программе ping). В результате хост-получатель возвращает эхо-от- 
вет ICMB ане сообщение о недоступности порта. Промежуточные маршрутизато- 
ры по-прежнему возвращают сообщение «истекло время в пути». 


Примечание В последних версиях traceroute ecmo опция -Т, имитирующая 
такое же поведение. Подобную версию можно получить на сай- 


me [tp;//ftp.ee.lbl gov/traceroute.tar.Z. 


Наверное, это изменение сделано исходя из соображения о TOM, что UDP-71- 
таграммы часто отфильтровываются маршрутизаторами, тогда как эхо-запросы 
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и эхо-ответы {СМР используемые программой ping, менее подвержены этому. 
Исходная версия traceroute также применяла эхо-запросы для определения 
маршрута, но потом они были заменены UDP-zararpaMMaMH, поскольку многие 
маршрутизаторы строго следовали предписанию RFC 792 [Postel 1981], требую- 
щему не посылать ІСМР-сообщения в ответ на [СМР-сообщения [Jacobson 1999]. 
Действующее ныне КЕС 1122 [Braden 1989] указывает, что ІСМР-сообщение не 
должно посылаться в ответ Ha ІСМР-сообщение об ошибке, но tracert по-пре- 
жнему встречает трудности в старых моделях маршрутизаторов. 

В ВЕС 1393 [Malkin 1993] предложено добавить новую опцию в протокол IP 
и отдельное ІСМР-сообщение, чтобы гарантировать надежность traceroute (a за- 
одно и решить некоторые другие задачи), но, так как в маршрутизаторы и про- 
граммное обеспечение хостов пришлось бы вносить изменения, этот метод не по- 
лучил распространения. 


Резюме 


Утилита traceroute — очень полезный инструмент для диагностики сете- 
вых ошибок, изучения маршрутизации и исследования топологии сети. Тополо- 
гия Internet нередко достаточно запутанна, и это может быть причиной неожи- 
данного поведения приложений. С помощью traceroute зачастую удается 
обнаружить аномалии в сети, из-за которых программа ведет себя странно. 

Программы traceroute и tracert работают путем отправки хосту назначе- 
HHA датаграммы с последовательно увеличивающимся значением в поле TTL. 3a- 
тем они отслеживают приходящие от промежуточных маршрутизаторов ICMP- 
сообщения «истекло время в пути». Разница B TOM, что traceroute посылает 
ОРР-датаграммы, a tracert ~ эхо-запросы ICMP. 


Совет 36. Используйте программу “ср 


Часто необходимо иметь утилиту, которая может посылать произвольный объем 
данных другой (или той же самой) машине по протоколу ТСР или ОПР и соби- 
рать статистическую информацию о полученных результатах. В этой книге уже на- 
писано несколько программ такого рода. В этом разделе вы познакомитесь с го- 
товым инструментом, обладающим той же функциональностью. Подобное сред- 
ство можно использовать для тестирования собственного приложения или для по- 
лучения информации о производительности конкретного стека TCP/IP или сети. 
Такая информация может оказаться бесценной на этапе создания прототипа. 

Этот инструмент — программа ЕЕ ср, бесплатно распространяемая Лабораторией 
баллистических исследований армии США (BRL — Ballistics Research Laboratory). Ее 
авторы Майк Муусс (автор программы ping) и Терри Слэттери. Эта утилита доступна 
на множестве сайтов B Internet. В книге будет использована версия, которую Джон 
Лин модифицировал с целью включения дополнительной статистики; ее можно 
получить по анонимному FTP с сайта gwen.cs.purdue.edu из каталога /pub/lin. Версия 
без модификаций Лина находится, например, на сайте ftp.sgi.com в каталоге sgi/ 
Src/ttcp, в состав ее дистрибутива входит также страница руководства. 

У программы ttcp есть несколько опций, позволяющих управлять: объемом 
посылаемых данных, длиной отдельных операций записи и считывания, размерами 
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буферов приема и передачи сокета, включением или отключением алгоритма Ней- 


гла и даже 
о порядке 


выравниванием буферов в памяти. На рис. 4.11 приведена информация 
использования (ср. Дается перевод на русский язык, хотя оригиналь- 


ная программа, естественно, выводит справку по-английски. 


Порядок вызова: ttep -t [-опции] хост [ < іп) 


Часто 
-1 


-u 
-P 


Опции, 
-n 


ttep -r [-опции > out] 
используемые опции: 
## длина в байтах буферов, в которые происходит считывание 
из сети и запись в сеть (по умолчанию 8192) 
использовать UDP, а не ТСР 
## номер порта, в который надо посылать данные или 
прослушивать (по умолчанию 5001) 
-t: отправить данные в сеть 
-r: считать (и отбросить) все данные из сети 
выравнивать начало каждого буфера на эту границу 
(по умолчанию 16384) 
считать, что буфер начинается с этого смещения 
относительно границы (по умолчанию 0) 
печатать более подробную статистику 
установить опцию сокета SO DEBUG 
## установить размер буфера сокета (если поддерживает 
операционная система) 
X формат для вычисления скорости обмена: К,К = кило (бит, байт); 
m,M = Mera; g,G = гига 
употребляемые вместе C -t: 
## число буферов, записываемых в сеть (по умолчанию 2048) 


-D не буферизовать запись по протоколу ТСР (установить 


Опции, 
-В 


-T 


опцию сокета TCP. NODELAY) 
употребляемые вместе с -r: 
для -S, выводить только полные блоки в соответствии 
c опцией -1 (для TAR) 
"touch": обращаться к каждому прочитанному байту 


Рис. 4.11. Порядок вызова ttcp 


Поэкспериментируем с размером буфера передачи сокета. Сначала прогоним 
тест с размером буфера, выбранным по умолчанию, чтобы получить точку отсчета. 
В одном окне запустим экземпляр Е ср-потребителя: 


bsd: $ ttcp -rsv 


a B другом 


~ экземпляр, играющий роль источника: 


bsd: $ ttcp -tev bsd 


ttcp-t: 


buflen-8192, nbuf-2048, а1191=16384/0, port-5013 tcp -> bsd 


ttcp-t: socket 
ttcp-t: connect 
ttcp-t: 16777216 bytes in 1.341030 real seconds 


= 12217.474628 KB/sec (95.449021 Mb/sec) 


ttcp-t: 16777216 bytes in 0.00 CPU seconds 


- 16384000.000000 KB/cpu sec 
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ttcp-t: 2048 I/O calls, msec/call = 0.67, calls/sec = 1527.18 
ttcp-t: buffer address 0х8050000 
раз: $ 


Как видите, Е ср дает информацию о производительности. Для передачи 16 Мб 
потребовалось около 1,3 с. 


Примечание Аналогичная статистика печатается принимающим процессом, но 
поскольку цифры, по существу, такие же, они здесь не приводятся. 


Также был выполнен мониторинг обмена с помощью tcpdump. Вот типичная 
строка выдачи: 


13:05:44.084576 bsd.1061 > bsd.5013: . 1:1449 (1448) 
ack 1win17376 «nop,nop,timestamp 11306 11306» (DF) 


Из нее видно, uro ТСР посылает сегменты по 1448 байт. 
Теперь следует установить размер буфера передачи равным 1448 байт, и по- 
вторить эксперимент. Приемник данных нужно оставить без изменения. 


bsd: $ ttcp -tsvb 1448 bsd 
ttcp-t: socket 
ttcp-t:  sndbuf 
ttcp-t: connect 
ttcp-t:  buflen-8192, nbuf-2048, align-16384/0, port-5013, 
sockbufsizez1448 tcp -> bsd 
ttcp-t: 16777216 bytes in 2457.246699 real seconds 
= 6.667625 KB/sec (0.052091 Mb/sec) 
ttcp-t: 16777216 bytes in 0.00 CPU seconds 
- 16384000.000000 KB/cpu sec 
ttcp-t: 2048 I/O calls, msec/call = 1228.62, calls/sec = 0.83 
ttcp-t: buffer address 0x8050000 
раз: $ 


На этот раз передача заняла почти 41 мин. Следует отметить, что, хотя по ча- 
сам для передачи потребовалось больше 40 мин, время, затраченное процессором, 
по-прежнему очень мало, даже не поддается измерению. Поэтому, что бы ни про- 
изощло, это не связано с загрузкой процессора. 

Теперь посмотрим, что показывает tcpdump. На рис. 4.12 приведены четыре 
типичные строки: 


16:03:57.168093 bsd.1187 > bsd.5013: P 8193:9641 (1448) 
ack 1 win 17376 «nop,nop,timestamp 44802 44802> (DF) 
16:03:57.368034 bsd.5013 » bsd.1187: . ack 9641 win 17376 
«nop,nop,timestamp 44802 44802» (DF) 
16:03:57.368071 bsd.1187 » bsd.5013: P 9641:11089(1448) 
ack 1 win 17376 «nop,nop,timestamp 44802 44802» (DF) 
16:03:57.568038 bsd.5013 » bsd.1187: . ack 11089 win 17376 
«nop,nop,timestamp 44802 44802» (DF) 


Рис. 4.12. Типичная выдача tcpdump для запуска ср -tsvb 1448 bsd 
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Обратите внимание, что время между последовательными сегментами со- 
ставляет почти 200 мс. Возникает подозрение, что тут замешано взаимодействие между 
алгоритмами Нейгла и отложенного подтверждения (совет 24). И действительно 
именно АСК задерживаются. 

Эту гипотезу можно проверить, отключив алгоритм Нейгла с помощью опции 
-р. Повторим эксперимент: 


bsd: $ ttep -tsvDb 1448 bsd 
ttcp-t:  buflen-8192, nbuf-2048, align-16384/0, рогі=5013, 
Sockbufsizez1448 tcp -> bsd 
ttcp-t: socket 
ttcp-t:  sndbuf 
ttcp-t: connect 
ttcp-t: поде1ау 
ttcp-t: 16777216 bytes in 2457.396882 real seconds 
= 6.667218 KB/sec (0.052088 Mb/sec) 
ttcp-t: 16777216 bytes in 0.00 CPU seconds 
- 16384000.000000 KB/cpu sec 
ttcp-t: 2048 I/O calls, msec/call = 1228.70, calls/sec = 0.83 
ttcp-t: buffer address 0х8050000 
bds: $ 


Как ни странно, ничего не изменилось. 


Примечание Это пример того, как опасно делать поспешные заключения. Сто- 
ило немного подумать и стало бы ясно, что алгоритм Нейгла 
тут ни при чем, так как посылаются заполненные сегменты. 
В частности, этому служит самый первый тест, — чтобы 
определить величину MSS. 


В совете 39 будут рассмотрены средства трассировки системных вызовов. То- 
гда вы вернетесь к этому примеру и обнаружите, что выполняемая t tcp операция 
записи не возвращает управление в течение примерно 1,2 с. Косвенное указание 
на это видно и из выдачи Е Е ср, где каждый вызов операции ввода/вывода занима- 
ет приблизительно 1,228 мс. Но, как говорилось в совете 15, ТСР обычно не бло- 
кирует операции записи, пока буфер передачи не окажется заполненным. Таким 
образом, становится понятно, что происходит. Когда ttcp записывает 8192 байта, 
ядро копирует первые 1448 байт в буфер сокета, после чего блокирует процесс, так 
как места в буфере больше нет. ТСР посылает все эти байты в одном сегменте, но 
послать больше не может, так как в буфере ничего не осталось. 


Примечание Из рис. 4.12 видно, что дело обстоит именно так, поскольку 
в каждом отправленном сегменте задан флаг PSH, а стеки, беру- 
щие начало в системе BSD, устанавливают этот флаг только 
тогда, когда выполненная операция передачи опустошает буфер. 


Поскольку приемник данных ничего не посылает в ответ, запускается меха- 
низм отложенного подтверждения, из-за которого АСК не возвращается до исте- 
чения тайм-аута в 200 мс. 
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В первом тесте ТСР мог продолжать посылать заполненные сегменты данных, 
поскольку буфер передачи был достаточно велик (16 Кб на машине bsd) для со- 
хранения нескольких сегментов. Трассировка системных вызовов для этого теста 
показывает, что на операцию записи уходит около 0,3 мс. 

Этот пример наглядно демонстрирует, как важно, чтобы буфер передачи от- 
правителя был, по крайней мере, не меньше буфера приема получателя. Хотя по- 
лучатель был готов принимать данные и дальше, но в выходном буфере отправи- 
теля задержался последний посланный сегмент. Забыть про него нельзя, пока не 
придет АСК, говорящий о том, что данные дошли до получателя. Поскольку раз- 
мер одного сегмента значительно меньше, чем буфер приема (16 Кб), его получе- 
ние не приводит к обновлению окна (совет 15). Поэтому АСК задерживается на 
200 мс. Подробнее о размерах буферов рассказано в совете 32. 

Однако смысл этого примера в том, чтобы показать, как можно использовать 
ttcp для проверки эффекта установки тех или иных параметров ТСР-соединения. 
Вы также видели, как анализ информации, полученной от t tcp, tcpdump и програм- 
мы трассировки системных вызовов, может объяснить работу ТСР. 

Следует упомянуть о том, как использовать программу ЕЕ ср для организации 
«сетевого конвейера» между хостами. Например, скопировать всю иерархию ка- 
талогов с хоста А на хост В. На хосте В вводите команду 


ttcp -rB | tar -xpf - 
на хосте А — команду 
tar -cf - каталог | ttcp -t A 


Можно распространить конвейер на несколько машин, если на промежуточ- 
ных запустить команду 


ttcp -r | ttcp -t следующий узел 


Резюме 


В этом разделе показано, как пользоваться программой t tcp для эксперимен- 
тирования с различными параметрами ТСР-соединения. ЕЕ ср можно применять 
также в целях тестирования собственных приложений, предоставляя для них ис- 
точник или приемник данных, работающий по протоколу ТСР либо ОПР И, нако- 
нец, вы видели, как использовать t Е ср для организации сетевого конвейера меж- 
ду двумя или более машинами. 


Совет 37. Применяйте программу [501 


В сетевом (и не только) программировании часто необходимо определить, какой 
процесс открыл файл или сокет. Особенно это важно в сетевом окружении, по- 
скольку, как было показано в совете 16, при завершении процесса, работавшего 
с cokeTOM, FIN не будет послан, если другой процесс держит этот сокет открытым. 

Хотя ситуация, когда другой процесс держит сокет открытым, выглядит 
странно, но она часто возникает, особенно при работе в UNIX. Происходит вот 
что: один процесс принимает соединение и запускает другой процесс, который 
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будет работать с этим соединением (кстати, именно это и делает inetd - совет 17). 
Если процесс, принявший соединение, не закроет сокет после создания процесса — 
потомка, то счетчик ссылок на это сокет будет равен двум. Поэтому после того как 
потомок закроет сокет, соединение останется открытым, и Е[М не будет послан. 

Та же проблема может возникнуть и по другой причине. Предположим, что 
хост клиента, работавшего с созданным процессом, аварийно остановился, в ре- 
зультате чего потомок «завис». Такая ситуация обсуждалась в совете 10. Если про- 
цесс, принимающий соединения, завершит работу, то перезапустить его будет не- 
возможно (если, конечно, не была задана опция сокета SO REUSEADDR, ~ совет 23), 
так как локальный порт уже привязан к созданному процессу. 

В этих и некоторых других случаях необходимо знать, какой процесс (или про- 
цессы) держит сокет открытым. Утилита netstat (совет 38) сообщает, uro неко- 
торый процесс занимает данный порт или адрес, но что это за процесс, неизвестно. 
В некоторых версиях UNIX для ответа на этот вопрос есть программа fstat. Вик- 
тор Абель (Victor Abell) написал свободно распространяемую программу 1sof, pa- 
ботающую почти во всех версиях UNIX. 


ее Ar Зо t 
Примечание Дистрибутив [50] можно получить по анонимному FTP с сайта 
vic.ccpurdue.edu из каталога pub/tools/unix/lsof. 


lsof — это исключительно гибкая программа; руководство по ней занимает 26 
печатных страниц. С ее помощью можно получить самую разнообразную инфор- 
мацию об открытых файлах. Как и в случае tcpdump, предоставление единого HH- 
терфейса к нескольким диалектам UNIX - это существенное достоинство. 

Рассмотрим некоторые возможности 1sof, полезные в сетевом программирова- 
нии. В руководстве приводится подробная информация и о других ее применениях. 

Предположим, что после выполнения команды netstat -af inet (совет 38) 
вы обнаруживаете, что некоторый процесс прослушивает порт 6000: 


Active Internet connections (including servers) 
Proto Recv-Q Send-Q Local Address Foreign Address (state) 
tcp 0 0 *.6000 х.ж LISTEN 


Порт 6000 не относится к хорошо известным (совет 18), поэтому возникает 
вопрос: что же ero прослушивает? Как уже упоминалось, в netstat по этому по- 
воду ничего не говорится — она лишь сообщает о наличии прослушивающего про- 
цесса. Зато программа lsof не испытывает никаких затруднений: 


bsd# 1воЕ -i TCP:6000 


COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 
XF86 Mach 253 root Ou inetO0xf5d98840 OtO TCP *:6000 (LISTEN) 
bsd£& 


Следует отметить, что вы запускали lsof от имени пользователя root. Это необ- 
ходимо, потому что используемая версия 1sof сконфигурирована для перечисле- 
ния файлов, принадлежащих только данному пользователю, за исключением ситуа- 
ции, когда ее запускает root. Это свойство направлено на обеспечение безопасности, 
но его можно отключить во время компиляции программы. Далее надо отметить, 
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что процесс был запущен пользователем root с помощью команды ХЕ86_Масн. Это 
ваш Х-сервер. 

Опция -i ТСР: 6000 означает, что 1sof должна искать открытые ТСР-сокеты, 
привязанные к порту 6000. Можно было бы показать все ТСР-сокеты с помощью 
опции -i ТСР или все TCP- и ОРр-сокеты - с помощью опции -1. 

Предположим, что вы еще раз запустили netstat и обнаружили, что кто-то 
открыл ЕТР-соединение с хостом vic.cc.purdue. edu: 


Active Internet connections 
Proto Recv-Q Send-Q Local Address Foreign Address (state) 
tcp 0 0 bsd.1124 vic.cc.purdue.edu.ftp ESTABLISHED 


Выяснить, кто это сделал, поможет 1sof: 


Ьза# 1воЕ -i Gvic.cc.purdue.edu 


COMMAND PID USER FD ТУРЕ DEVICE SIZE/OFF NODE NAME 

ftp 450 jcs Зи inet Oxf5d99f00 0+0 ТСР рѕа:1124-> 
vic.cc.purdue.edu:ftp ESTABLISHED 

bsd# 


Как обычно, в имени машины bsd опущен домен и строка разбита на две. Из 
полученной выдачи видно, что ЕТР-соединение открыл пользователь jcs. 

Необходимо подчеркнуть, что Lsof может выдать информацию только об откры- 
тых файлах. Собственно говоря, название программы — аббревиатура list open files (пе- 
речислить открытые файлы). Это, в частности, означает, что с ее помощью нельзя 
получить информацию о ТСР-соединениях, находящихся в состоянии TIME-WAIT 
(совет 22), поскольку с ними не связан никакой открытый сокет или файл. 


Резюме 


Здесь показано, как можно воспользоваться утилитой lsof для получения OT- 
вета на разнообразные вопросы об открытых файлах. К сожалению, нет версии 
lsof для Windows. 


Совет 38. Используйте программу netstat 


Ядро операционной системы ведет разнообразную статистику об объектах, 
имеющих отношение к сети. Эту информацию можно получить с помощью про- 
граммы netstat. Существует четыре вида запросов. 


Активные сокеты 


Во-первых, можно получить сведения об активных сокетах. Хотя netstat дает 
информацию о разных типах сокетов, интерес представляют только сокеты из адрес- 
ных доменов inet (AF, INET) и UNIX (AF. LOCAL или AF, UNIX). Можно потребовать 
вывести все типы сокетов или выбрать один тип, указав адресное семейство C по- 
мощью опции - f. 

По умолчанию серверы, сокеты которых привязаны к адресу INADDR ANY, не 
выводятся, но этот режим можно отключить с помощью опции -а. Например, если 
нужны ТСР/ОПР-сокеты, то можно вызвать netstat так: 
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bsd: $ netstat -f inet 
Active Internet connections 


Proto Recv-Q Send-Q 


tcp 
tcp 
udp 
udp 


bsd: 


Здесь показан только сервер доменных имен (named), работающий на машине 
bsd. Если же нужно вывести все серверы, то программа запускается таким образом: 


$ 


0 


0 
0 
0 


0 


оо о 


Local Address 
localhost.domain 


bsd.domain 


localhost.domain 


bsd.domain 


bsd: $ netstat -af inet 
Active Internet connections 
Proto Recv-Q Send-Q 


tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 
udp 


bsd: 


ооо оо ооо оо оо оо оо о о о о о о оо о о о оо о о о о о осо 


0 


ооо оо о о о оо о о о о о о о о о о о о о о о о о оо оо 


Local Address 
*.6000 
.Smtp 
.printer 
.rlnum 
.tcpmux 
.chargen 
.discard 
. echo 
.time 
.daytime 
.finger 
.login 

. cmd 
.telnet 
.ftp 
.1022 
.2049 
1023 


+ + +t +*+ +*+ ++ X X + X X + A 


localhost .domain 


bsd.domain 
* .udpecho 
.chargen 
.discard 
. echo 
.time 
.ntalk 
.biff 
1011 
.nfsd 
.1023 
.sunrpc 
*.1024 


хх + +*+ 0X € +*+ X 


localhost.domain 


bsd.domain 
*.syslog 


Foreign Address 


+ ж 


* 
* 


* 


* 


хх жж 00b + ++ ++ хх + хх + + + + + хх X X OX + хх X 0o хх + X + + 
ов * ©. e à у 


Инструменты и ресурсы 


+ + + +*+ 


+ + + +*+ ++ + + хх + х + 0X 0X t A + + 0X 0X + х + + + хх + 


Foreign Address 


(state) 
LISTEN 
LISTEN 


(state) 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
LISTEN 
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Если бы вы запустили программу 1sof (совет 37), то обнаружили, что боль- 
шинство этих «серверов» — в действительности inetd (совет 17), ожидающий 
прихода соединений или датаграмм в порты стандартных сервисов. Слово 
«LISTEN» в колонке state для ТСР-соединений означает, что сервер ждет запро- 
са на соединение от клиента. 

Если обратиться к серверу эхо-контроля с помощью telnet: 


bsd: $ telnet bsd echo 
TO появится соединение в состоянии ESTABLISHED: 


Proto Recv-Q Send-Q Local Address Foreign Address (state) 


tcp 0 0 bsd.echo bsd.1035 ESTABLISHED 
tcp 0 0 bsd.1035 bsd.echo ESTABLISHED 
tcp 0 0 *.echo *.* LISTEN 


Здесь опущены строки, He относящиеся к серверу эхо-контроля. Обратите 
внимание, что, поскольку вы соединились с локальной машиной, в выдаче 
netstat соединение присутствует дважды: один раз для клиента, а другой — для 
сервера. Заметьте также, что inetd продолжает прослушивать порт в ожидании 
дальнейших соединений. 


Примечание Последнее замечание требует еще нескольких пояснений. Хотя 
telnet-knueum подсоединился к порту 7 (порт эхо) и фактически 
использует его в качестве порта назначения, хост продолжает 
прослушивать этот порт. Это нормально, так как с точки зре- 
ния ТСР соединение — это четверка, состоящая из локальных IP- 
адреса и порта и удаленных ІР-адреса и порта (совет 23). Как 
видите, inetd прослушивает порт на универсальном «псевдо- 
адресе» INADDR, ANY, что показано звездочкой в колонке Local 
Address, тогда как [Р-адрес для установленного соединения pa- 
вен bsd. Если бы вы создали одно дополнительное соединение 
с помощью telnet, то получили бы еще две строки, аналогичные 
первым двум, только порт клиента был бы отличен от 1035. 


Завершите работу клиента и снова запустите netstat. Вот что вы получите: 


Proto Recv-Q Send-Q Local Address Foreign Address (state) 
tcp 0 0 bsd.1035 bsd.echo TIME WAIT 


Как видно, клиентская сторона соединения находится в состоянии TIME-WAIT 
(совет 22). В колонке state могут появляться и другие состояния, подробнее 
о них рассказывается в ВЕС 793 [Postel 1981b]. 


Интерфейсы 


С помощью net stat можно также получить информацию об интерфейсах. Ta- 
кой пример был приведен в совете 7. Основная информация выдается при нали- 
ЧИИ опции - i: 
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bsd: $ netstat -1 


Мате Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll 
ed0 1500 «Linlo 00.00.c0.54.53.73 40841 0 5793 0 0 
ed0 1500 172.30 bsd 40841 0 5793 0 0 
tun0* 1500 «Link» 397 0 451 0 0 
tun0* 1500 205.184,142 205.184.142.171 397 0 451 0 0 
$10* 552 «Linlo 0 0 0 0 0 
100 16384 «Link» 353 0 353 0 0 
100 16384 127 localhost 353 0 353 0 0 


Отсюда видно, что в машине bsd сконфигурировано четыре интерфейса. Hep- 
вый — ed0— это адаптер сети Ethernet. Он входит в частную (RFC 1918 [Rekhter, 
Moskowitz et al. 1996]) сеть 172.30.0.0. Адрес 00.00.c0.54.73 — это первый 
в списке МАС-адресов (media access control — контроль доступа к носителю) дан- 
ной сетевой карты. Через этот интерфейс прошло 40841 входных пакетов и 5793 
выходных; не было зарегистрировано ни ошибок, ни коллизий. MTU (совет 7) co- 
ставляет 1500 байт — максимальное значение для сетей Ethernet. 

Интерфейс tun0 — это телефонный канал, по которому связь осуществляется 
по протоколу РРР (Point-to-Point Protocol). Он входит в сеть 205.184.142.0. MTU 
для этого интерфейса также составляет 1500 байт. 

Интерфейс з10 — это телефонный канал, по которому связь осуществляется 
по протоколу SLIP (Serial Line Internet Protocol), RFC 1055 [Romkey 1988]. Это 
еще один, ныне устаревший протокол двухточечного соединения по телефонным 
линиям. Данный интерфейс в машине bsd не используется. 

Наконец, есть еще возвратный интерфейс 100. О нем уже неоднократно говорилось. 

В сочетании с опцией -i можно также задать опции -b или -d. Тогда будет 
напечатано количество байт, прошедших через интерфейс в обе стороны, или чис- 
ло отброшенных пакетов. 


Маршрутная таблица 


Кроме того, netstat может дать маршрутную таблицу. Назначьте опцию -п, 
чтобы получить не символические имена, a ІР-адреса; так лучше видно, в какие 
сети маршрутизируются пакеты. 

Интерфейсы и соединения, выведенные на рис. 4.13, показаны и на рис. 4.14. 
Интерфейс 100 не показан, так как полностью находится внутри машины bed. 


bsd: $ netstat -rn 
Routing tables 


Internet: 

Destination Gateway Flags Refs Use Netif Expire 
default 163.179.44.41 UGSc 2 0 tunO 
127.0.0.1 127.0.0.1 UH 1 34 100 
163.179.44.41 205.184.142.171 UH 3 0 tunO 

172.30 link#1 UC 0 0 еао 
172.30.0.1 0:0:c0:54:53:73 | UHLW 0 132 100 


Рис. 4.13. Маршрутная таблица, выведенная программой netstat 


Программа netstat ПИТ 1277 


172.30.0.1 163.179.44.41 


205.184.142.171 


172.30 


(телефонное 
подключение) 


Маршрутизатор 
сервис-провайдера 


Рис. 4.14. Информация об интерфейсах и хостах, выведенная программой netstat 


Прежде чем знакомиться с отдельными элементами этой выдачи, обсудим на- 
значение колонок. В первой колонке находится пункт назначения маршрута. Это 
может быть конкретный хост, сеть или маршрут по умолчанию. 

В колонке Flags печатаются различные флаги, большая часть которых зави- 
сит от реализации. Следует упомянуть только следующие: 


а U – маршрут задействован («UP»); 

о Н ~ маршрут к хосту. Если этот флаг отсутствует, то речь идет о маршруте 
к сети (или к подсети, если используется бесклассовая междоменная марш- 
рутизация СТОК - совет 2); 

о G – непрямой маршрут. Иными словами, пункт назначения не связан напря- 
мую с данным хостом, к нему следует добираться через промежуточный мар- 
шрутизатор или шлюз (С — gateway). 


Легко сделать ошибку, полагая, что флаги Н и С взаимоисключающие, то есть 
маршрут может идти либо к хосту (Н), либо к промежуточному шлюзу (с). Флаг H 
означает, что адрес в первой колонке представляет собой полный ІР-адрес хоста. 
Если флага Н нет, то адрес в этой колонке не содержит идентификатора хоста, ины- 
ми словами, OH — адрес сети. Флаг С показывает, достижим ли адрес, проставлен- 
ный в первой колонке, непосредственно с данного хоста или необходимо пройти 
через промежуточный маршрутизатор. 


.1 192.168.2 .2 


172.20 


Рис. 4.15. H2 выступает B роли шлюза к НЗ 


Вполне возможно, что для некоторого маршрута будут одновременно установ- 
лены флаги С и Н. Рассмотрим, например, две сети, изображенные на рис. 4.15. 
Хосты H1 и H2 подключены к сети Ethernet с адресом 172.20. Хост НЗ соединен 
с Н2 по РРР-линии с сетевым адресом 198.168.2. 
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Маршрут к H3 в маршрутной таблице H1 будет выглядеть так: 


Destination Gateway Flags Refs Use  Netif Expire 
192.168.2.2 172.20.10.2 ОСН 0 0 edo 


Флаг Н установлен потому, что 192.168.2.2 — полный адрес хоста. А флаг 
G — так как H1 не имеет прямого соединения с НЗ и должен идти через хост H2 
(172.20.10.2). Обратите внимание, что на рис. 4.13 для маршрута к хосту 
163.179.44.41 нет флага С, поскольку этот хост напрямую подключен к интерфей- 
cy сипо (205.184.142.171) в машине bsd. 

На рис. 2.9 в маршрутной таблице H1 не должно быть записи для H3. Вместо 
нее присутствует запись для подсети 190.50.2, поскольку именно в этом состоит 
смысл организации подсетей — уменьшить размеры маршрутных таблиц. Запись 
в маршрутной таблице Н1 для этой подсети выглядела бы так: 


Destination Gateway Flags Refs Use Netif Expire 
190.50.2 190.50.1.4 UG 0 0 edO 


Флаг H не установлен, так как 190.50.2 — адрес подсети, a не отдельного хоста. 
Имеется флаг С, так как H3 не соединен напрямую c H1. Датаграммы or H3 x H1 
должны проходить через маршрутизатор R1 (190.50.1.4). 

Смысл колонки Gateway зависит от того, есть флаг С или нет. Если маршрут 
непрямой (флаг С есть), то в колонке Gateway находится ІР-адрес следующего 
узла (шлюза). Если же флага С нет, то в этой колонке печатается информация 
о том, как достичь напрямую подсоединенного пункта назначения. Во многих pea- 
лизациях это всегда ІР-адрес интерфейса, к которому и подсоединен пункт Ha3Ha- 
чения. В реализациях, производных от BSD, это может быть также МАС-адрес, как 
показано в последней строке на рис. 4.13. В таком случае будет установлен флаг L. 

Колонка ВеЁз содержит счетчик ссылок на маршрут, то есть количество ак- 
тивных пользователей этого маршрута. 

Колонка Use указывает, сколько пакетов было послано по этому маршруту, а KOJIOH- 
ка Net if содержит имя ассоциированного сетевого интерфейса, который представляет 
собой тот же объект, о котором вы получаете информацию с помощью опции -1. 

Теперь, разобравшись, что означают колонки, печатаемые командой net stat 
-rn, вернемся к рис. 4.13. 

Первая строка на этом рисунке описывает маршрут по умолчанию. Именно по 
нему отсылаются датаграммы, когда в маршрутной таблице нет более точного мар- 
шрута. Например, если выполнить команду ping netcom4.netcom.com, то полу- 
чится такой результат: 


bsd: $ ping netcom4.netcom.com 
PING netcomd.netcom.com (199.183.9.104): 56 data bytes 
64 bytes from 199.183.9.104: icmp seq-0 tt1-248 time-268.604 ms 


Поскольку нет маршрута ни до хоста 199.183.9.104, ни до сети, содержащей 
этой хост, эхо-запросы [СМР (совет 33) посылаются по маршруту по умолчанию. 
В соответствии с первой строкой выдачи netstat шлюз для этого маршрута HMe- 
ет адрес 163.179.44.41, туда и посылается датаграмма. Строка 3 на рис. 4.13 пока- 
зывает, что есть прямой маршрут к хосту 163.179.44.41, и отсылать ему дата- 
граммы следует через интерфейс с ІР-адресом 205.184.142.171. 


ПЕР 1 279, 


Строка 2 в выдаче — это маршрут для возвратного адреса (127.0.0.1). Посколь- 
ку это адрес хоста, установлен флаг Н. Так как хост подсоединен напрямую, то 
имеется и флаг С. А в колонке Gateway вы видите [Р-адрес интерфейса 100. 

В строке 4 представлен маршрут к локальной сети Ethernet. В связи с тем, что 
Ha машине bsd установлена операционная система, производная oT BSD, в колон- 
ке Gateway находится строка Link#1. В других системах был бы просто напечатан 
[Р-адрес интерфейса, подсоединенного к локальной сети (172.30.0.1). 


Программа netstat 


Статистика протоколов 


С помощью netstat можно получить статистику протоколов. Если задать оп- 
ЦИЮ -5, ТО netstat напечатает статистические данные по протоколам IP, ICMP, 
[СМР UDP и ТСР. Если нужен какой-то один протокол, то его можно указать по- 
средством опции -р. Так, для получения статистики по протоколу ПОР следует 
ввести следующую команду: 


bsd: $ netstat -вр пар 
цар: 
82 datagrams received 
with incomplete header 
with bad data length field 
with bad checksum 
dropped due to no socket 
broadcast/multicast datagrams dropped due to no socket 
dropped due to full socket buffers 
0 not for hashed pcb 
81 delivered 
82 datagrams output 
bsd: S 


оонооо 


Ниже дается перевод на русский язык, программа netstat использует англий- 
СКИЙ, 


чар: 
82 датаграмм получено 
с неполным заголовком 
с неправильным значением в поле длины данных 
с неправильной контрольной суммой 
отброшено из-за отсутствия сокета 
отброшено широковещательных/ групповых датаграмм 
из-за отсутствия сокета 
0 отброшено из-за переполнения буфера сокета 
0 He для хэшированного блока управления протоколом 
81 доставлено 
82 отправлено датаграмм 


овооо 


Можно отменить печать строк с нулевыми значениями, если дважды задать OII- 
ЦИЮ - S: 


bsd: $ netstat -ssp чар 
udp: 
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82 datagrams received 
1 dropped due to no socket 
81 delivered 
82 datagrams output 
bsd: $ 


Периодический просмотр статистики ТСР оказывает очень «отрезвляющее» 
действие. На машине bsd netstat выводит для ТСР 45 статистических показате- 
лей. Вот строки с ненулевыми значениями, которые были получены при запуске 
netstat-ssp tcp: 


tcp: 
446 packets sent 
190 data packets (40474 bytes) 
213 ack-only packets (166 delayed) 
18 window update packets 
32 control packets 
405 packets received 
193 acks (for 40488 bytes) 
12 duplicate acks 
302 packets (211353 bytes) received in sequence 
10 completely duplicate packets (4380 bytes) 
22 out-of-order packets (16114 bytes) 
2 window update packets 
20 connection requests 
2 connection accepts 
13 connections established (including accepts) 
22 connection closed (including 0 drops) 
3 connections updated cached RTT on close 
3 connections updated cached RTT variance on close 
2 embryonic connections dropped 
193 segments updated rtt (of 201 attempts) 
31 correct АСК header predictions 
180 correct data packet header predictions 


Далее дается перевод статистической информации на русский язык. 


tcp: 

446 пакетов послано 
190 пакетов данных (40474 байта) 
213 пакетов, содержащих только ack (166 отложенных) 
18 пакетов с обновлением окна 
32 контрольных пакета 

405 пакетов принято 
193 ack (на 40488 байт) 
12 повторных ack 
302 пакета (211353 байта) получено по порядку 
10 пакетов ~ полных дубликатов (4380 байт) 
22 пакета не по порядку (16114 байта) 
2 пакета с обновлением окна 
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20 запросов на соединение 
2 приема соединения 
13 соединений установлено (включая принятые) 
22 соединения закрыто (включая 0 сброшенных} 
3 соединения при закрытии обновили RTT в кэше 
3 соединения при закрытии обновили дисперсию RTT в кэше 
2 эмбриональных соединения сброшено 
193 сегмента обновили rtt (из 201 попыток) 
31 правильное предсказание заголовка АСК 
180 правильных предсказаний заголовка пакета с данными 


Эта статистика получена после перезагрузки машины bsd и последовавших за 
ней отправки и получения нескольких сообщений по электронной почте, а также 
чтения нескольких телеконференций. Если предположить, что такие события, как 
доставка пакетов не по порядку или получение дубликатов пакетов, происходят 
очень редко, то полученная информация полностью развеет эти иллюзии. Так, из 
405 полученных пакетов 10 оказались дубликатами, а 22 пришли не по порядку. 


Примечание В работе [Bennett et al. 1999 ] показано, что приход пакетов не no 
порядку не обязательно свидетельствует о неисправности. Так- 
же объясняется, почему в будущем следует ожидать широкого 
распространения этого явления. 


Программа netstat B Windows 


Выше рассмотрено, как работает программа netstat в системе UNIX. B Win- 
dows тоже есть аналогичная программа, принимающая в основном те же опции 
и выдающая такие же данные. Формат выдачи очень напоминает то, что вы виде- 
ли, хотя состав информации не такой полный. 


Резюме 


Здесь приведены утилита net stat и те сведения о системе, которые можно IO- 
лучить с ее помощью. netstat сообщает об активных сокетах, o сконфигуриро- 
ванных сетевых интерфейсах, о маршрутной таблице и о статистике протоколов. 
Иными словами, она выдает отчеты о самых разнообразных аспектах сетевой подсис- 
темы, причем в различных форматах. 


Совет 39. Применяйте средства 
трассировки системных вызовов 


Иногда при отладке сетевых приложений нужно уметь трассировать обраще- 
ния к ядру операционной системы. Вы уже встречались с подобной ситуацией 
в совете 36 и вскоре вернетесь к этому примеру. 

В большинстве операционных систем есть разные способы трассировки сис- 
темных вызовов. B BSD это утилита ktrace, в SVR4 (и Solaris) — truss, a B Li- 
nux — strace, 
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Все эти программы похожи, поэтому остановимся только на kt race. Беглого 
знакомства с руководством по truss или strace должно быть достаточно для 
применения аналогичной методики в других системах. 


Преждевременное завершение 


Первый пример - это вариация на тему первой версии программы shutdownc 
(листинг 3.1), которая разработана в совете 16. Идея программ badclient 
и shutdownc та же: читаются данные из стандартного ввода, пока не будет полу- 
чен признак конца файла. В этот момент вы вызываете shutdown для отправки 
FIN-cerMeHTa удаленному хосту, а затем продолжаете читать от него данные, пока 
не получите EOF, что служит признаком прекращения передачи удаленным хос- 
том. Текст программы badclient приведен в листинге 4.2. 


Листинг 4.2. Некорректный эхо-клиент 


badclient.c 
1 $include "etcp.h" 
2 int main( int argc, char **argv ) 


3 { 
4 SOCKET s; 
5 fd_set readmask; 
6 fd_set allreads; 
7 int rc; 
8 int len; 
9 char lin[ 1024 }; 
10 char lout[ 1024 ]; 
11 ІМІТ(); 
12 S = tcp client( argv[ optind ], argv[ optind + 1 ] ); 
13 FD ZERO( &allreads ); 
14 FD SET( 0, &allreads ); 
15 FD SET( s, &allreads ); 
16 for ( ;; ) 
17 { 
18 readmask = allreads; 
19 rc = select( s + 1, &readmask, NULL, NULL, NULL ); 
20 if C rc <= D ) 
21 error( 1, errno, "select вернула ($d)", rc ); 
22 if ( FD ISSET( s, &readmask ) ) 
23 ( 
24 rc = гесу( s, lin, sizeof( lin ) - 1,0); 
25 if fore € 0. 
26 error( 1, errno, "ошибка вызова recv" ); 
27 if (гс == 0 ) 
28 error( 1, 0, "сервер отсоединился\п" ); 
29 lin[ rc } = '\0:; 
30 if ( fputs( lin, stdout ) ) 
31 error( 1, errno, "ошибка вызова fputs" ); 


Трассировка системных вызовов 


| 283. 


33 if ( FD ISSET( 0, &readmask ) ) 

34 { 

35 if ( fgets( lout, sizeof( lout ), stdin ) == NULL ) 
36 ( 

37 if ( shutdown( s, 1 ) ) 

38 error( 1, errno, "ошибка вызова shutdown" ); 
39 } 

40 е1 зе 

41 { 

42 len = strlen( lout ); 

43 rc - send( s, lout, len, O0 ); 

44 if (rc «0 ) 

45 error( 1, errno, "ошибка вызова send" ); 

46 ) 

47 } 

48 } 

49 } 


badclient.c 


22-32 Если select показывает, что произошло событие чтения на соедине- 
нии, пытаемся читать данные. Если получен признак конца файла, то 
удаленный хост прекратил передачу, поэтому завершаем работу. В про- 
тивном случае выводим только что прочитанные данные на stdout. 


33-47 


Если select показывает, что произошло событие чтения Hà стандарт- 


ном вводе, вызываем fgets для чтения данных. Если fgets возвращает 
NULL, что является признаком ошибки или конца файла, TO вызываем 
shutdown, чтобы сообщить удаленному хосту о прекращении передачи. 
В противном случае посылаем только что прочитанные данные. 


А теперь посмотрим, что произойдет при запуске программы badclient.B ka- 
честве сервера в этом эксперименте будет использоваться программа Е среспо (ли- 
стинг 3.2). Следует напомнить (совет 16), что вы можете задать число секунд, на 
которое t cpecho должна задержать отправку ответа на запрос. Установите задерж- 
ку в 30 c. Запустив клиент, напечатайте hello и сразу нажмите Ctrl+D, таким 
образом посылается fgets признак конца файла. 


bsd: $ tcpecho 9000 30 
спустя 30 c 
tcpecho: ошибка вызова recv: 
Connection reset by peer (54) 
bsd: $ 


bsd: $ badclient bsd 9000 
hello 


^D 
badclient: сервер отсоединился 
bsd: $ 


Как видите, badclient завершает сеанс сразу же с сообщением о том, что сер- 
вер отсоединился. Ho t cpecho продолжает работать и «спит», пока не истечет 30 c 
тайм-аута. После этого программа получает от своего партнера ошибку Соппес- 


tion reset by peer. 


Это удивительно. Ожидалось, что ссресћо через 30 c пошлет эхо-ответ, а за- 
тем завершит сеанс, прочтя признак конца файла. Вместо этого badclient завер- 
шает работу немедленно, а t Cpecho получает ошибку чтения. 
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Правильнее начать исследование проблемы с использования tcpdump (совет 
34), чтобы понять, что же на самом деле посылают и принимают обе программы. 
Выдача tcpdump приведена на рис. 4.16. Здесь опущены строки, относящиеся 
к фазе установления соединения, и разбиты длинные строки. 


1 18:39:48.535212 bsd.2027 > bsd.9000: 
P 1:7(6) ack 1 win 17376 «nop,nop,timestamp 742414 742400» (DF) 
2 18:39:48.546773 bsd.9000 » bsd.2027: 
ack 7 win 17376 «nop,nop,timestamp 742414 742414» (DF) 
3 18:39:49.413285 bsd.2027 > bsd.9000: 
F 7:7(0) ack 1 win 17376 «nop,nop,timestamp 742415 742414» (DF) 
4 18:39:49.413311 bsd.9000 » bsd.2027: 
ack 8 win 17376 «nop,nop,timestamp 742415 742415» (DF) 
5 18:40:18.537119 bsd.9000 > bsd.2027: 
P 1:7(6) ack 8 win 17376 «nop,nop,timestamp 742474 742415» (DF) 
6 18:40:18.537180 bsd.2027 » bsd.9000: 
R 2059690956:2059690956(0) win O 


Рис. 4.16. Текст, выведенный tepdump для программы badclient 


Все выглядит нормально, кроме последней строки. Программа badclient посы- 
лает tcpecho строку hello (строка 1), а спустя секунду появляется сегмент FIN, по- 
сланный в результате shutdown (строка 3). Программа tcpecho в обоих случаях OT- 
вечает сегментом АСК (строки 2 и 4). Через 30 c послетого, как badclient отправила 
hello, tcpecho отсылает эту строку назад (строка 5), но другая сторона вместо того, 
чтобы послать АСК, возвращает RST (строка 6), что и приводит к печати сообщения 
Connection reset by peer. RST был послан, поскольку программа badclient уже 
завершила сеанс. 

Но все же видно, что tcpecho ничего не сделала для преждевременного завер- 
шения работы клиента, так что вся вина целиком лежит Ha badclient. Посмот- 
рим, что же происходит внутри badclient, поможет в этом трассировка систем- 
НЫХ ВЫЗОВОВ. 

Повторим эксперимент, только на этот раз следует запустить программу так: 


bsd: $ ktrace badclient bsd 9000 


При этом badclient работает, как и раньше, HO дополнительно вы получаете 
трассу выполняемых системных вызовов. По умолчанию трасса записывается в файл 
КЕгасе . out. Для печати содержимого этого файла надо воспользоваться программой 
kdump. Результаты показаны Ha рис. 4.17, в котором опущено несколько начальных 
вызовов, относящихся к запуску приложения и установлению соединения. 

Первые два поля в каждой строке - это идентификатор процесса и имя испол- 
няемой программы. В строке 1 вы видите вызов read c дескриптором fd, равным 
(stdin). В строке 2 читается шесть байт (GIO — сокращение or general I/O - об- 
щий ввод/вывод), содержащих hello\n. В строке 3 показано, что вызов read 
вернул 6 — число прочитанных байтов. Аналогично из строк 4-6 видно, что 
программа badclient писала в дескриптор 3, который соответствует сокету, соединен- 
ному с tcpecho. Далее, в строках 7 и 8 показан вызов select, вернувший единицу. 
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1 4692 badclient CALL read(0,0x804e000,0x10000) 
2 4692 badclient GIO fd 0 read 6 bytes 
"hello 
3 4692 badclient RET read 6 
4 4692 badclient CALL sendto(0x3,0xefbfce68,0x6,0,0,0) 
5 4692 badclient GIO fd 3 wrote 6 bytes 
"hello 
6 4692 badclient RET sendto 6 
7 4692 badclient CALL select(0x4,0xefbfd6f0,0,0,0) 
8 4692 badclient RET select 1 
9 4692 badclient CALL read(0,0x804e000,0x10000) 
10 4692 badclient GIOfd 0 read 0 bytes 
11 4692 badclient RET read 0 
12 4692 badclient CALL shutdown (0x3 , 0x1) 
13 4692 badclient RET shutdown 0 
14 4692 badclient CALL select(Ox4,0xefbfd6f0,0,0,0) 
15 4692 badclient RET select 1 
16 4692 badclient CALL shutdown(0x3,0x1) 
17 4692 badclient RET shutdown 0 
18 4692 badclient CALL select (0x4,0xefbfd6f0,0,0,0) 
19 4692 badclient RET select 2 
20 4692 badclient CALL recvfrom(0x3,0xefbfd268,0x3ff,0,0,0) 
21 4692 badclient GIO fd 3 read 0 bytes 
22 4692 badclient RET recvfrom 0 
23 4692 badclient CALL write(0x2,0xefbfc6f4,0xb) 
24 4692 badclient GIO fd 2 wrote 11 bytes 
"badclient: " 
25 4692 badclient RET write 11/0xb 
26 4692 badclient CALL write(0x2,0xefbfc700,0x14) 
27 4692 badclient GIO fd 2 wrote 20 bytes 
"server disconnected 
28 4692 badclient RET write 20/0x14 
29 4692 badclient CALL exit (0x1) 


Рис. 4.17. Результаты прогона badclient под управлением ktrace 


Это означает, что произошло одно событие. В строках 9-11 badclient прочитала 
EOF из stdin и вызвала shutdown (строки 12 и 13). 

До сих пор все шло нормально, но вот в строках 14-17 вас поджидает сюрп- 
pus: select возвращает одиночное событие, и снова вызывается shut down. Озна- 
комившись C листингом 4.2, вы видите, что такое возможно только при условии, 
если дескриптор 0 снова готов для чтения. Но read не вызывается, как можно 
было бы ожидать, ибо fgets в момент нажатия Ctrl+D отметила, что поток нахо- 
дится в конце файла, поэтому она возвращается, не выполняя чтения. 
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Примечание Вы можете убедиться в этом, познакомившись с эталонной реали- 
зацией fgets (на основе fgetc) в книге [Kernighan and Ritchie 1988]. 


В строках 18 и 19 select возвращает информацию o событиях на обоих де- 
скрипторах stdin и сокете. В строках 20-22 видно, что recvf£rom возвращает нуль 
(конец файла), а оставшаяся часть трассы показывает, как badclient выводит со- 
общение об ошибке и завершает сеанс. 

Теперь ясно, что произошло: select показывает, что стандартный ввод готов 
для чтения в строке 15, поскольку вы забыли вызвать FD. CLR для stdin после nep- 
вого обращения к shutdown. А следующий (уже второй) вызов shutdown вынуж- 
дает ТСР закрыть соединение. 


Примечание Вэтом можно убедиться, посмотрев код на странице 1014 кни- 
ги [Wright and Stevens 1995], где показано, что в результате об- 
ращения x shutdown вызывается функция Еср_изгс1о5е4. 
Если shutdown уже вызывался раньше, то соединение находит- 
ся в состоянии FIN- WAIT-2 и Еср_изгс1овеа вызывает функ- 
цию soisdisconnected (строка 444 на странице 1021). Этот 
вызов окончательно закрывает сокет и заставляет select вер- 
нуть событие чтения. А в результате будет прочитан ЕОЕ 


Поскольку соединение закрыто, recvf rom возвращает нуль, то есть признак KOH- 
ца файла, и badclient выводит сообщение «сервер отсоединился» и завершает сеанс. 

Ключ к пониманию событий в этом примере дал второй вызов shutdown. Лег- 
ко обнаружилось отсутствующее обращение к FD. CLR. 


Низкая производительность ttcp 


Следующая ситуация — это продолжение примера из совета 36. Помните, что 
при размере буфера равном MSS соединения, время передачи 16 Мб возросло c 1,3 
с до почти 41 мин. 

На рис. 4.18 приведена репрезентативная выборка из результатов прогона КЕгасе 
для этого примера. 


12512 ttcp 0.000023 CALL write(0x3,0x8050000, 0x2000) 
12512 ttcp 1.199605 GIO fd 3 wrote 8192 bytes 

12512 ttcp 0.000442 RET write 8192/0x2000 

12512 tbep .000022 CALL мигібсе (0х3, 0х8050000, 0x2000) 
12512 ttcp 1.199574 GIO fd 3 wrote 8192 bytes 


e 


12512 ttcp 0.000442 RET write 8192/0x2000 
12512 ttcp 0.000023 CALL  write(0x3,0x8050000, 0x2000) 
12512 ttcp 1.199514 GIO fd 3 wrote 8192 bytes 


12512 ttcp 0.000432 RET write 8192/0x2000 


Рис. 4.18. Выборка из результатов проверки Нср -tsvb 1448 bsd под управлением 
ktrace 


Анализ ICMP - сообщений МЕ || 1287 


Вызвана kdump со следующими опциями: 
kdump -R -m -1 


для печати интервалов времени между вызовами и запрета вывода 8 Кб данных, 
ассоциированных с каждым системным вызовом. 

Время каждой операции записи колеблется около значения 1,2 с. На рис. 4.19 
для сравнения приведены результаты эталонного теста. На этот раз разброс значе- 
ний несколько больше, но среднее время записи составляет менее 0,5 мс. 

Большее время в записях типа GIO на рис. 4.18 по сравнению с временем на 
рис. 4.19 наводит на мысль, что операции записи блокировались в ядре (совет 36). Тог- 
да становится понятна истинная причина столь резкого увеличения времени передачи. 


12601 ttcp 0.000033 CALL  write(0x3,0x8050000, 0x2000) 
12601 ttcp 0.000279 GIO fd 3 wrote 8192 bytes 

12601 ttcp 0.000360 RET write 8192/0x2000 

12601 ttep .000033 CALL  write(0x3,0x8050000, 0x2000) 
12601 ttcp 0.000527 GIO fd 3 wrote 8192 bytes 


ин 


Ce 


12601 ttcp 0.000499 RET write 8192/0x2000 
12601 ttcp 0.000032 CALL  write(0x3,0x8050000, 0x2000) 
12601 ttcp 0.000282 GIO fd 3 wrote 8192 bytes 


12601 ttcp 0.000403 RET write 8192/0x2000 


Рис. 4.19. Репрезентативная выборка из результатов проверки ttep -tsv bsd 
под управлением ktrace 


Резюме 


Здесь описано два способа применения утилиты трассировки системных вы- 
зовов. В первом примере ошибку удалось обнаружить путем анализа системных 
вызовов, выполненных приложением. Во втором примере надо было отслеживать 
не очередность системных вызовов, а время выполнения некоторых из них. 

Ранее уже говорилось о том, что для выяснения причин аномального поведения 
программы часто бывает необходимо сопоставить результаты, полученные от раз- 
личных утилит. Программы трассировки системных вызовов, такие как Кігасе, 
truss и strace, — этоеще одно средство анализа в арсенале сетевого программиста. 


Совет 40. Создание и применение программы 
для анализа ІСМР-сообщений 


Иногда необходимо знать, какие сообщения приходят в протоколе ICMP. Ko- 
нечно, для их перехвата всегда можно воспользоваться программой tcpdump или 
другим сетевым анализатором, но иногда простой инструмент оказывается более 
удобным, Применение tcpdump влечет за собой некоторое снижение производи- 
тельности, а также угрозу безопасности, хотя прослушивание ІСМР-сообщений 
совершенно безобидно и ненакладно. 
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Во-первых, для работы такового сетевого анализатора, как tcpdump, нужно пе- 
ревести сетевой интерфейс в режим пропускания. Это увеличивает нагрузку на 
центральный процессор, так как прерывание будет возникать при проходе через 
интерфейс каждого пакета Ethernet, даже если он адресован He той машине, на 
которой работает анализатор. 

Во-вторых, во многих организациях применение сетевых анализаторов огра- 
ничено или вообще запрещено из-за потенциальной опасности перехвата инфор- 
мации и кражи паролей. Поэтому чтение [СМР-сообщений там более приемлемо. 

В данном разделе разработан инструмент, который позволяет отслеживать [СМР- 
сообщения и не имеет недостатков, присущих сетевому анализатору общего назначе- 
ния. Это позволит изучить простые сокеты, с которыми вы пока не сталкивались. 

В совете 33 упоминалось, что [СМР-сообщения транспортируются в составе IP- 
датаграмм. Обычно содержимое ІСМР-сообщения зависит от ero типа, но интерес 
представляют только поля icmp type и icmp code, показанные на рис. 4.20. Допол- 
нительные поля будут рассмотрены в связи с сообщениями о недоступности ресурса. 


0 78 15 16 31 


Тип Код 


Содержимое, зависящее 
оттипа и кода 


Рис. 4.20. Общий формат ІСМР-сообщения 


Часто возникают недоразумения при ответе на вопрос, что такое простые со- 
кеты и для чего они нужны. Простые сокеты нельзя использовать для перехвата 
ТСР-сегментов или ООР-датаграмм, поскольку они таким сокетам не передают- 
ся. Не годятся они и для получения всех ІСМР-сообщений. Например, в системах, 
производных от BSD, эхо-запросы [СМР запросы о временном штампе и запросы 
маски адреса полностью обрабатываются ядром и не передаются простым сокетам. 
В общем случае простой сокет получает все [Р-датаграммы, в заголовках которых 
указан неизвестный ядру протокол, большинство ІСМР-сообщений и все без ис- 
ключения ІСМР-сообщения. 

Важно также отметить, что в простой сокет поступает вся ІР-датаграмма це- 
ликом, включая заголовок. Ваша программа должна будет пропускать IP-aaro- 
JIOBOK. 


Чтение ІСМР-сообщений 
Начнем с включаемых в программу файлов и функции main (листинг 4.3). 


Листинг 4.3. Функция тат программы стр 


icmp.c 


1 #1пс1аае <sys/types.h> 
2 #1пс1аае «netinet/in systm.h» 


Анализ ICMP - сообщений 


#incluđe «netinet/in-h» 
*include «netinet/ip.h» 
*include «netinet/ip icmp.h» 


$include "etcp.h" 


3 
4 
5 
6 #1пс1аае «netinet/udp.h» 
7 
8 


int main( int argc, char **argv ) 


28 
29 } 


SOCKET s; 

struct protoent *pp; 
int rc; 

char icmpdg[ 1024 ]; 


INIT(); 
рр = getprotobyname( "icmp" ); 
if ( pp == NULL ) 
error( 1, errno, "ошибка вызова getprotobyname" 
S = Socket( AF INET, SOCK RAW, pp-»p proto ); 
if ( !isvalidsock( s ) ) 
error( 1, errno, "ошибка вызова Socket" ); 


for ( ;; ) 
{ 
rc = recvfrom( s, icmpdg, sizeof( icmpdg ), 0, 
NULL, NULL ); 
if (ус < 0) 
error( 1, errno, "ошибка вызова recvfrom" ); 
print dg( icmpdg, rc ); 


Открытие простого сокета 
15-20 Поскольку использован простой сокет, надо указать нужный прото-кол. 
Вызов функции getprotobyname возвращает структуру, содержа- 
щую номер протокола ICMP. Обратите внимание, что в качестве типа 
указана константа SOCK, RAW, а не SOCK. STREAM или SOCK, DGRAM, как 


раньше. 


Цикл обработки событий 


21-28 Читаем каждую ІР-датаграмму, используя recvfrom, как и в случае 
ООР-датаграмм. Для печати поступающих ІСМР-сообщений вызыва- 


ем функцию print dg. 


Печать ІСМР-сообщений 


Далее рассмотрим форматирование и печать ІСМР-сообшений. Это делает 
функция print. dg, показанная в листинге 4.4. Передаваемый этой функции 6y- 
фер имеет структуру, показанную на рис. 4.21. 

Из puc. 4.21 видно, что буфер содержит ІР-заголовок, за которым идет соб- 
ственно [СМР-сообщение. 


Т 1289 


rs 


icmp.c 
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0 34 78 15 16 31 


Длина 
Берсин заголовка Тип сервиса еар na 
(28-7) | (ip hi) 
Смещение 
Время Контрольная сумма 


Адрес источника 
(ip src) 


Адрес назначения 
(ip dst) 


Опции IP (если есть) 


Тип Код Контрольная сумма 
(icmp. type) (icmp. code) ІСМР-сообщения 


Дополнительные ІСМР-данные 


м ІР-заголовок а 


ОЕ = флаг «не фрагментировать» 
MF = флаг «есть еще фрагменты» 


Рис. 4.21. ІСМР-сообщение, передаваемое функции print dg 


Листинг 4.4. Функция print dg 


icmp.c 
static void print, dg( char *dg, int len ) 
( 


1 

2 

3 struct ip *ip; 

4 struct icmp *icmp; 
5 struct hostent *hp; 
6 char *hname; 

7 

8 


int №1; 
Static char *redirect code[] - 
9 { 
10 "сеть", "хост", 
11 "тип сервиса и сеть", "тип сервиса и хост" 
12 3 
13 static char *timexceed code[] - 
14 { 
15 "транзите", "сборке" 
16 }; 
17 Static char *param code[] = 


18 ( 


Анализ ICMP - сообщений НТ | | |291 


19 
20 


21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 } 


"Плохой ТР-заголовок", "Нет обязательной опции" 


ір = ( struct ip * )dg; 
if ( ip-»ip v 1=4) 


error( 0, 0, "ТР-датаграмма He версии 4\n" ); 
return; 


hl = ip-»ip hl << 2; /* Длина ТР-заголовка в байтах. */ 
if ( len < hl + ICMP. MINLEN ) 


error( 0, 0, "short datagram ($d bytes) from %s\n", 
len, inet ntoa( ip-»ip src ) ); 


return; 
) 
Һр = gethostbyaddr( ( char * )&ip-»ip src, 4, AF INET ); 
if ( hp == NULL ) 
hname = ""; 
else 
hname = hp-»h name; 
icmp = ( struct icmp * )( dg + hl); /* ТСМР-пакет. */ 


printf( "ICMP $s ($d) от $s (%5) \п", 

get type( icmp-»icmp type ), 

icmp-»icmp type, hname, inet ntoa( ip-»ip src ) ); 
if ( icmp-»icmp type == ICMP UNREACH ) 

print, unreachable( icmp ); 


else if ( icmp-»icmp type == ICMP REDIRECT ) 
printf( "\ЕПеренаправление Ha %5\п", icmp-»icmp. code <= 3 ? 
redirect code[ icmp-»icmp code |] : "Некорректный код" ); 
else if ( icmp-»icmp type == ICMP TIMXCEED ) 
printf( "\ЕТТЬ == 0 при $sWMn", icmp-»icmp code <= 1 ? 
timexceed code[ icmp-»icmp code ] : "Некорректный код" ); 
else if ( icmp-»icmp type -- ICMP PARAMPROB ) 
printf( "\6%5\п", icmp-»icmp code <= 1 ? 
param code[ icmp-»icmp. code ] : "Некорректный код" ); 


icmp.c 


Получение указателя Ha ІР-заголовок и проверка корректности пакета 


21 


22-26 


27-33 


Записываем в переменную 1р указатель на только что прочитанную 
датаграмму, приведенный к типу struct ip *. 

Поле ip. v - это версия протокола IP. Если протокол не совпадает 
c IPv4, то печатаем сообщение об ошибке и выходим. 

Поле ip. hl содержит длину заголовка в 32-байтных словах. Умножа- 
ем его на 4, чтобы получить длину в байтах, и сохраняем результат 
в переменной hl. Затем проверяем, что длина ІСМР-сообщения не 
меньше минимально допустимой величины. 
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Получение имени хоста отправителя 
34-38 Используем адрес источника в ІСМР-сообщении, чтобы найти имя XO- 


ста отправителя. Если gethostbyaddr вернет NULL, то записываем 
в hname пустую строку, в обратном случае — имя хоста. 


Пропуск ІР-заголовка и печать отправителя и типа 
39-42 Устанавливаем указатель icmp на первый байт, следующий за 1Р-заго- 


ловком. Этот указатель используется далее для получения типа ICMP- 
сообщения (icmp type) и печати типа, адреса и имени хоста отпра- 
вителя. Для получения АЗСП-представления типа [СМР вызываем 
функцию get, type, текст которой приведен в листинге 4.5. 


Печать информации, соответствующей типу 
43-44 Если это одно из ІСМР-сообщений о недоступности, TO вызываем функ- 


45-47 


48-50 


51-53 


цию print unreachable (листинг 4.6) для печати дополнительной 
информации. 

Если это сообщение о перенаправлении, то получаем тип перенаправ- 
ления из поля icmp, code и печатаем ero. 

Если это сообщение об истечении времени существования, из поля 
icmp. code узнаем, произошло ли это во время транзита или сборки 
датаграммы, и печатаем результат. 

Если это сообщение о некорректном параметре, из поля icmp, code 
определяем, в чем ошибка, и печатаем результат. 


Функция get type очевидна. Вы проверяете допустимость кода типа и воз- 
вращаете указатель на соответствующую строку (листинг 4.5). 


Листинг 4.5. Функция get type 


icmp.c 


lstatic char *get type( unsigned icmptype ) 


2{ 
3 


( 


static char *type[] - 


"Эхо-ответ", /* 0 */ 
"ICMP Tun 1", /* 1 */ 
"ICMP Тиц 2", /* 2 */ 
"Пункт назначения недоступен", /* 3 *J 
"Источник приостановлен", /* 4 */ 
"Перенаправление", А 
"ТСМР Тип 6", /* 6 y 
"ICMP Tun 7", [5 Жу 
"Эхо-запрос", /* 8 */ 
"Отклик маршрутизатора", pu e oer 
"Поиск маршрутизаторов", уе OEC oe 
"Истекло время существования", /* 11 */ 
"Неверный параметр", [5c a 
“Запрос временного штампа", уж X3 */ 
"Ответ на запрос временного штампа", /* 14 */ 
"Запрос информации", /* 15 */ 
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21 "Ответ на запрос информации", /* 16 * 
22 "Запрос маски адреса", [* 17 
23 "Ответ на запрос маски адреса" /* 18 */ 
24 ); 


25 if ( icmptype « ( sizeof( type ) / sizeof( type[ 0 ] ) ) ) 
26 return type[ icmptype |]; 
27 return "НЕИЗВЕСТНЫЙ ТИП"; 
28 ) 
icmp.c 


Последняя функция - это print, unreachable. ІСМР-сообщения o недоступно- 
сти содержат ІР-заголовок и первые восемь байт той ІР-датаграммы, из-за которой 
было сгенерировано сообщение о недоступности. Это позволяет узнать адреса и но- 
мера портов отправителя и предполагаемого получателя недоставленного сообщения. 

Структура ІР-датаграммы, прочитанной из простого сокета в составе ICMP- 
сообщения о недоступности, показана на рис. 4.22. Та часть, которую уже обрабо- 
тала функция print_dg, заштрихована, она не передается в print unreachable. 
Приведены также входной параметр функции print unreachable - icmp и ло- 


кальные переменные ip и udp. 
ICMP- UDP- 
8 20 0-40 8 
icmp ip udp 


20 байт 


Рис. 4.22. ІСМР-сообщение о недоступности 


Функция print unreachable извлекает информацию из заголовка и первых 
восьми байт включенной ІР-датаграммы. Хотя вы пометили байты как UDP-3a- 
головок, это мог быть и заголовок ТСР: номера портов в обоих случаях находятся 
в одной и той же позиции. Формат ООР-заголовка показан на рис. 4.23. 


15 16 


Номер порта источника Номер порта назначения 
(uh,sport) (uh, dport) 


Рис. 4.23. UDP-saronoBok 


Текст функции print, unreachable приведен в листинге 4.6. 


Листинг 4.6. Функция print unreachable 


icmp.c 
1 static void print unreachable( struct icmp *істр ) 
2 { 
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3 struct ip *ip; 

4 struct udphdr *udp; 

5 char laddr[ 15 + 1 ]; 

6 static char *unreach[] = 
7 

8 


( 


"Сеть недоступна", ОЙ 
9 "Хост недоступен", [Bde 
10 "Протокол недоступен", /* 2 */ 
11 "Порт недоступен", Е */ 
12 "Нужна фрагментация, поднят бит DF", /* 4 */ 
13 "Ошибка маршрутизации от источника", "DOES S7 
14 "Сеть назначения неизвестна", /* 6 */ 
15 "Хост назначения неизвестен", /* 7 */ 
16 "Хост источника изолирован", /* 8 */ 
17 "Сеть назначения закрыта администратором ", /* 9 */ 
18 "Хост назначения закрыт администратором ", /* 10 */ 
19 "Сеть недоступна для типа сервиса", /* 11 */ 
20 "Хост недоступен для типа сервиса", /* 12 */ 
21 "Связь запрещена администратором", /* 13 */ 
22 "Нарушение предшествования хостов", /* 14 */ 
23 "Действует отсечка предшествования" /* 15 */ 
24 ); 
25 ip = ( struct ip * )( ( char * )icmp + 8 3; 
26 udp = ( struct udphdr * )( ( char * )ip + ( ip-»ip hl << 2 ) ); 


27 strcpy( laddr, inet ntoa( ip-»ip sro ) ); 
28 printf( "\Е%5\п\ЕИст.: %5.%а, HasH.: %5.%а\п", 


29 icmp-»icmp code < ( sizeof( unreach ) / 
30 sizeof( unreach[ 0 ] ) )? 
31 unreach[ icmp->icmp_code ] : "Некорректный код", 


32 laddr, ntohs( udp-»uh sport ), 
33 inet ntoa( ір->ір dst ), ntohs( udp-»uh dport ) ); 
34) 
icmp.c 


Установка указателей иполучение адреса источника 


25-26 Начинаем с установки указателей ip и чар соответственно на [Р-заго- 
ловок и первые восемь байт вложенной 1Р-датаграммы. 

27 Копируем адрес источника из [Р-заголовка в локальную переменную 
laddr. 


Печать адресов, портов и типа сообщения 


28-33 Печатаем адреса и номера портов источника и назначения, а также 
уточненный тип сообщения о недоступности. 


В качестве примера использования программы ICMP приведено несколько 
последних ІСМР-сообщений, полученных при запуске traceroute (совет 35). 


traceroute -q 1 netcom4.netcom.com 


Опция -q 1 означает, что traceroute должна посылать пробный запрос толь- 
ко один раз, а не три, как принято по умолчанию. 
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ICMP Истекло время существования (11) от hi-0.mig-fl-gw1.icg.net 
(165.236.144.110) 

TTL == 0 во время транзита 
ТСМР Истекло время существования (11) от s10-0-0.dfw-tx- 
gwl.icg.net (165.236.32.74) 

TTL == 0 во время транзита 
ТСМР Истекло время существования (11) от dfw-tx-gw2.icg.net 
(163.179.1133) 

TTL == 0 Bo время транзита 
ICMP Пункт назначения недоступен (3) от netcom4.netcom.com 
(199.183.9.104) 

Порт недоступен 

Ист. 205.184.142.71.45935, Назн. 199.183.9.104.33441 


Обычно нет необходимости следить с помощью icmp за работой traceroute, 
но это может быть очень полезно для поиска причин отсутствия связи. 


Резюме 


В этом разделе разработан инструмент для перехвата и печати ICMP-cooó6- 
щений. Такая программа помогает при диагностике ошибок сети и маршрути- 
зации. 

В ходе разработки программы icmp использованы простые сокеты. Здесь вы 
познакомились с форматами IP- и ОРрР-датаграмм, а также со структурой ICMP- 
сообщений. 


Совет 41. Читайте книги Стивенса 


В сетевых конференциях чаще всего задают вопрос: «Какие книги нужно чи- 
тать, чтобы освоить TCP/IP?». В подавляющем большинстве ответов упоминают- 
ся книги Ричарда Стивенса. 

В этой книге много ссылок на работы Стивенса. Для сетевых программистов 
этот автор написал две серии книг: «TCP/IP Illustrated» в трех томах и «UNIX 
Network Programming» в двух. Они преследуют разные цели, поэтому рассмотрим 
их по отдельности. 


«TCP/IP Illustrated» 


Как следует из названия, серия «TCP/IP Illustrated» трактует работу наибо- 
лее распространенных протоколов из семейства TCP/IP и программ, в которых 
они применяются. В совете 14 говорилось, что основное средство для исследова- 
ния — это программа tcpdump. Запуская небольшие тестовые программы и наблю- 
дая за генерируемым ими сетевым трафиком, вы постепенно начинаете понимать, 
как на практике функционируют протоколы. 

Используя различные операционные системы, Стивенс показывает, что pea- 
лизации в них одного И того же протокола приводят к тонким отличиям в его ра- 
боте. Еще важнее, что вы учитесь ставить собственные эксперименты, а затем ин- 
терпретировать их результаты, отвечая тем самым на возникающие вопросы. 
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Поскольку в каждом томе семейство протоколов TCP/IP рассматривается 
под разными углами зрения, имеет смысл кратко охарактеризовать каждую 
книгу. 


Том 1: Протоколы 

В этом томе описываются классические протоколы TCP/IP и их взаимосвязи. 
Сначала рассматриваются протоколы канального уровня, такие как Ethernet, 
SLIP и PPP Далее автор переходит к протоколам ARP и RARP (Reverse Address 
Resolution Protocol — протокол определения адреса по местоположению узла сети) 
и рассматривает их в качестве связующего звена между канальным и межсетевым 
уровнями. 

Несколько глав посвящено протоколу IP и его связям с ICMP и маршрутиза- 
цией. Также анализируются утилиты ping и traceroute, работающие на уровне IP. 

Далее речь идет о протоколе UDP и смежных вопросах: широковещании и про- 
токоле IGMP. Описываются также основанные на UDP протоколы: DNS, TFTP 
(Trivial File Transfer Protocol – тривиальный протокол передачи файлов) и BOOTP 
(Bootstrap Protocol — протокол начальной загрузки по сети). 

Восемь глав посвящено протоколу ТСР. В нескольких главах обсуждаются 
распространенные приложения на базе TCP, такие как telnet, rlogin, FTP, SMTP 
(электронная почта) и NFS. 


Том 2: Реализация 

Второй том, написанный в соавторстве с Гэри Райтом (Gary Wright), — это прак- 
тически построчное описание сетевого кода из операционной системы Á.ABSD. По- 
скольку код из системы BSD широко признан как эталонная реализация, эта книга 
незаменима для тех, кто хочет лучше разбираться в реализации основных прото- 
колов семейства TCP/IP. 

В книге рассматривается реализация нескольких протоколов канального уровня 
(Ethernet, SLIP и возвратный интерфейс), протокола IP, маршрутизации, прото- 
колов ICMP, IGMP, UDP и TCP, группового вещания, уровня сокетов, а также He- 
сколько смежных тем. Поскольку автор приводит реальный код, читатель может 
получить представление о том, какие проблемы возникают при реализации слож- 
ной сетевой системы, и на какие компромиссы приходится идти. 


Том 3: ТСР для транзакций, HTTP, NNTP и протоколы B адресном домене UNIX 

Третий TOM — это продолжение первого и второго. Он начинается с описания 
протокола T/TCP и принципов его функционирования. Это описание построено 
так же, как и в первом томе. Далее приводится реализация Т/ТСР - по типу вто- 
рого тома. 

Во второй части рассматриваются два популярных прикладных протокола: 
HTTP (Hypertext Transfer Protocol — протокол передачи гипертекста) и NNTP 
(Network News Transfer Protocol — сетевой протокол передачи новостей), которые 
составляют основу сети World Wide Web и сетевых телеконференций Usenet со- 
ответственно. 
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И, наконец, исследуются сокеты в адресном домене UNIX и их реализация. 
По сути, это продолжение второго тома, не включенное в него из-за ограничений 
на объем издания. 


«UNIX Network Programming» 


В серии «UNIX Network Programming» приведена трактовка TCP/IP для при- 
кладных программистов. Здесь рассматриваются не сами протоколы, а их приме- 
нение для построения сетевых приложений. 


Том 1. Сетевые API: Сокеты и XTI 

Эта книга должна быть у каждого сетевого программиста. В ней очень подроб- 
но рассматривается программирование TCP/IP с помощью АР] сокетов и XTI. 
Помимо традиционных тем, обсуждаемых в изданиях по программированию вар- 
хитектуре клиент-сервер, в данной книге затрагиваются групповое вещание, мар- 
шрутизирующие сокеты, неблокирующий ввод/вывод, протокол IPv6 и ero рабо- 
ту совместно с IPv4, простые сокеты, программирование на канальном уровне 
и сокета B адресном домене UNIX. 

В этом томе есть особенно ценная глава, в которой сравниваются различные 
модели построения клиентов и серверов. В приложениях описываются виртуаль- 
ные сети и техника отладки. 


Том 2: Межпроцессное взаимодействие 

Во втором томе детально рассмотрены различные механизмы межпроцессного 
взаимодействия. Помимо таких традиционных средств, как каналы и FIFO в UNIX, 
очереди сообщений, семафоры и разделяемая память, впервые появившиеся в сис- 
теме SysV, обсуждаются и более современные методы межпроцессного взаимодей- 
ствия, предложенные в стандарте POSIX. 

Имеется прекрасное введение в изучение стандартизованных РОЗ[Х-потоков 
(threads) и использования в них таких примитивов синхронизации, как мьютексы, 
условные переменные и блокировки чтения-записи. Для тех, кто интересуется ра- 
ботой системных механизмов, Стивенс приводит реализацию нескольких прими- 
тивов синхронизации и очередей сообщений в стандарте POSIX. 

Заканчивается книга главами об КРС (Remote Procedure Calls — вызовы уда- 
ленных процедур) и подсистеме Solaris Doors. 

Был запланирован и третий том, в котором предполагалось рассмотреть при- 
ложения, но, к несчастью, Стивенс скончался, не успев его завершить. Частично 
материал, который он хотел включить в третий том, можно найти в первом изда- 
нии книги «UNIX Network Programming» [Stevens 1990]. 


Совет 42. Читайте тексты программ 


Начинающие программисты часто спрашивают более опытных коллег, откуда 
тем столько всего известно. Конечно, знания и опыт приобретаются разными CIIO- 
собами, но один Из самых важных, хотя и недооцениваемых, — это чтение про- 
грамм, написанных мастерами. 
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Расширяющееся движение за открытые исходные тексты облегчает эту за- 
дачу. Чтение и разбор высококачественного кода имеют множество плюсов, са- 
мое очевидное — это ознакомление с подходом, выбранным экспертом для реше- 
ния задачи. Вы можете применить такую методику в своих программах, немного ее 
модифицировав и адаптировав. При этом вырабатываются собственные приемы. 
1И когда-нибудь будут читать уже ваш код и восхищаться красивым решеним. 

Не так очевидно, хотя в некоторых отношениях более важно осознание того, 
что нет никакой магии. Начинающие программисты иногда склонны думать, что 
код операционной системы или реализации протоколов непостижим, он создает- 
ся высшими силами, а простым смертным нечего и пытаться в нем разобраться. 
Но, читая код, вы понимаете, что это просто образец хорошей (по большей части, 
стандартной) практики инженерного проектирования, и вам это тоже под силу. 

Короче говоря, изучая код, вы приходите к выводу, что глубокое и таинствен- 
ное — в действительности вопрос применения стандартных приемов, овладеваете 
этими приемами и учитесь применять их на практике. Читать код нелегко. Для это- 
го требуется высокая концентрация внимания, но усилия окупаются сторицей. 

Есть несколько источников хорошего кода, но лучше получить еще и коммен- 
тарии. Книга Лионса «А Commentary on the UNIX Operating System» [Lions 1977] 
давно уже ходила B списках. Недавно благодаря усилиям нескольких людей, в част- 
ности Денниса Ричи, и великодушию компании SCO, которая сейчас владеет Hc- 
ходными текстами UNIX, эта книга стала доступна широкой публике. 


Примечание Первоначально книгу могли приобрести только держатели ли- 
цензии на исходные тексты UNIX, но подпольная ксерокопия 
(или копия с ксерокопии) была вожделенным призом для многих 
программистов в дни становления UNIX. 


В книге приведен код очень ранней (шестой) версии операционной системы 
UNIX, в которой не было сетевых компонент, кроме ТТУ-терминалов c разделени- 
ем времени. Тем не менее стоит изучить этот код, даже если вы не интересуетесь 
системой UNIX, поскольку это прекрасный пример конструирования программ- 
ного обеспечения 

Еще одна отличная книга по операционным системам, включающая исходные 
тексты, – это «Operating Systems: Design and Implementation» [Tanenbaum and 
Woodhull, 1997]. В ней описана операционная система MINIX. Хотя в самом тек- 
сте сетевой код не приводится, но он есть на прилагаемом компакт-диске. 

Для тех, кого больше интересуют сетевые задачи, предназначен второй том 
книги «TCP/IP Illustrated» [Wright and Stevens 1995]. Она упоминалась в совете 41. 

В этой книге описывается код из системы BSD, на базе которой создано несколь- 
ко современных систем с открытыми исходными текстами (FreeBSD, OpenBSD, 
NetBSD). Она дает прекрасный материал для экспериментов с кодом. Оригиналь- 
ный код системы 4.4BSD Lite можно получить с ЕТР-сервера компании Walnut 


Creek CD-ROM (ftp://ftp.cdrom.com/pub/A4.4 BSD-L ite). 
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Во втором томе книги «Работа в сетях: TCP/IP» [Comer and Stevens 1999] 
описан другой стек TCP/IP. Как и в предыдущей, в ней приводится подробное 
объяснение принципа работы кода. Код можно загрузить из сети. 

Есть много и других источников кода, хотя, как правило, он не сопровождается 
пояснениями в виде книги. Начать можно с открытых систем UNIX или Linux. Для 
всех подобных проектов исходные тексты доступны на СО-КОМ или через ЕТР. 

В проекте GNU, основанном фондом Free Software Foundation, имеется исход- 
ный текст переписанных с нуля реализаций большинства стандартных утилит 
UNIX. Это тоже отличный материал для изучения. 

Информацию об этих проектах можно найти на следующих сайтах: 


о домашняя страница FreeBSD — http;//www.freebsd.org; 


a проект GNU http;//www.gnu.org; 
О архивы ядер Linux http://www.kernel.org; 


о домашняя страница NetBSD — http;//wwwnetbsd.org; 
о домашняя страница OpenBSD  http;//www.openbsd.org. 


В каждом из этих источников есть огромное количество исходных текстов, свя- 
занных с сетевым программированием, и их стоит изучить, даже если UNIX не 
находится в сфере ваших интересов. 


Резюме 


Один из лучших способов изучения сетевого программирования (да и любого 
другого) — это чтение программ, написанных людьми, уже достигшими вершин 
мастерства. До недавнего времени было нелегко получить доступ к исходным 
текстам операционных систем и их сетевых подсистем. Но в связи с распрост- 
ранением движения за открытость исходных текстов ситуация изменилась. Код 
нескольких реализаций стека TCP/IP и соответствующих утилит (telnet, ЕТР, 
шей ит.д.) доступен для проектов FreeBSD и Linux. Здесь приведены лишь HEKO- 
торые источники, в Internet можно найти множество других. 

Особенно полезны книги, в котрых есть не только код, но и подробные ком- 
ментарии к нему. 


Совет 43. Изучайте ВЕС 


Ранее говорилось, что спецификации семейства протоколов TCP/IP и связан- 
ные с ними архитектурные вопросы Internet содержатся в серии документов, объе- 
диненных названием Request for Comments (ВЕС – Предложения для обсужде- 
ния). На самом деле, КЕС, впервые появившиеся в 1969 году, – это не только 
спецификации протоколов. Их можно назвать рабочими документами, в которых 
обсуждаются разнообразные аспекты компьютерных коммуникаций и сетей. Не 
все RFC чисто технические, в них встречаются забавные наблюдения, пародии, 
стихи и просто различные высказывания. К концу 1999 года было более 2000 при- 
своенных ВЕС номеров, правда, некоторые из них так и не были опубликованы. 
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Хотя не в каждом ВЕС содержится какой-либо стандарт Internet, любой стан- 
дарт Internet опубликован в виде RFC. Материалам, входящим в подсерию КЕС, 
дается дополнительная метка «STDxxxx». Текущий список стандартов и тех RFC, 
которые находятся на пути принятия в качестве стандарта, опубликован в доку- 
менте 5700001. 

Не следует, однако, думать, что КЕС, не упомянутые в документе 5700001, 
лишены технической ценности. В некоторых описываются идеи пока еще разра- 
батываемых протоколов или направления исследовательских работ. Другие содер- 
жат информацию или отчеты о деятельности многочисленных рабочих групп, со- 
зданных по решению IETF (Internet Engineering Task Force — проблемная группа 
проектирования Internet). 


Тексты ВЕС 


Получить копии RFC можно разными путями, но самый простой — зайти на 
Ұер-страницу редактора ВЕС http;//www.fc-editor.org. На этой странице есть 
основанное на заполнении форм средство загрузки, значительно упрощающее по- 
иск. Есть также поиск по ключевым словам, позволяющий найти нужные RFC, 
если их номер неизвестен. Там же можно получить документы из подсерий STD, 
FYI и ВСР (Best Current Practices — лучшие современные решения). 

КЕС можно также переписать по FTP с сайта ftp.isiedu из каталога in-notes/ 
и из других ЕТР-архивов. 

Если у вас нет доступа по протоколам НТТР или ЕТР то можно заказать ко- 
пии RFC по электронной почте. Подробные инструкции о том, как сделать заказ, 
а также список ЕТР-сайтов вы получите, послав электронное сообщение по адре- 
су ríc-infoQisi.edu, включив одну строку: 


help: ways, to get rfcs 


Какой бы способ вы ни выбрали, прежде всего надо загрузить текущий указа- 
тель КЕС (файл rf£c-index.txt). После публикации ни номер, ни текст ВЕС уже 
не изменяются, так что единственный способ модифицировать КЕС - это выпус- 
тить другое КЕС, заменяющее предыдущее. Для каждого КЕС в указателе отмече- 
но, есть ли для Hero заменяющее RFC и если есть, To его номер. Там же указаны 
ВЕС, которые обновляют, но не замещают прежние. 

И, наконец, различные компании поставляют RFC на CD. Так, Walnut Creek 
CD-ROM (http;//www.cdrom.com) и InfoMagic (http;//www.infomagic.com) предла- 
гают компакт-диски, Ha которых записаны как ВЕС, так и другие документы, от- 
носящиеся к Internet. Разумеется, перечень RFC на таких дисках быстро стано- 
вится неполным, но, поскольку КЕС сами по себе не подлежат изменению, диск 
может устареть только в том смысле, что не содержит последних ВЕС. 


Совет 44. Участвуйте в конференциях Usenet 


Одно из самых ценных мест B Internet B плане получения советов и инфор- 
мации — это конференции Usenet, посвященные сетевому программированию. 
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Существуют конференции практически по любому аспекту сетевых технологий 
от прокладки кабелей (comp.dcom.cabling) до синхронизирующего сетевого прото- 
кола NTP (comp.protocols.time.ntp). 

Замечательная конференция, относящаяся к протоколам семейства TCP/IP 
и программированию с их помощью, — comp.protocols.tcp-ip. Всего лишь несколько 
минут, ежедневно потраченных на просмотр сообщений в этой конференции, даст 
массу полезной информации, советов и приемов. Обсуждаемые темы варьируют- 
ся от подключения к сети машины под управлением Windows до тонких техни- 
ческих вопросов по протоколам TCP/IP, их реализации и работы. 

В самом начале знакомства с конференциями по сетям вызвать недоумение 
может даже простое их перечисление (а их не меньше 70). Лучше всего начать 
с конференции comp.protocols.tcp-ip и, возможно, одной из конференций по конк- 
ретной операционной системе, например, comp.os.linux.networking или comp.ms- 
windows.programmer.tools.winsock. Сообщения в этих конференциях могут содер- 
жать ссылки на другие, более специальные конференции, которые тоже могут 
быть вам интересны или полезны. 

Один из лучших способов чему-то научиться в сетевых конференциях — это 
отвечать на вопросы. Изложив свои знания по конкретному вопросу в форме, по- 
нятной для других, вы сами глубже разберетесь в проблеме. Небольшое усилие, 
требуемое для составления ответа из 50—100 слов, окупится многократно. 

Отличное введение в систему конференций Usenet находится на сайте Инфор- 
мационного центра Usenet (http:;//metalab.unc.edu/usenet-i/). На этом сайте есть 
статьи по истории и использованию Usenet, а также краткая статистика для боль- 
щинства конференций, в том числе среднее число сообщений в день, среднее чис- 
ло читателей, адрес модератора (если таковой есть), где хранится архив (если он 
ведется) и ссылки на часто задаваемые вопросы (ЕАО) для каждой конференции. 

Ha сайте Информационного центра Usenet есть поисковая система, позволяю- 
щая найти конференции, в которых обсуждается интересующая вас тема. 

Выше упоминалось, что во многих конференциях ведутся ЕАО, с которыми 
стоит ознакомиться, прежде чем задавать вопрос. Если задать вопрос, на который 
уже есть ответ B FAQ, то, скорее всего, вас к нему и отошлют, а, может быть, и по- 
журят за нежелание потрудиться самому. 


Другие ресурсы, относящиеся к конференциям 


Следует упомянуть еще о двух ценных ресурсах, связанных с сетевыми кон- 
ференциями. Первый — это сайт DejaNews (http://www.deja.com). 


Примечание В мае 1999 сайт Deja News изменил свое название на Deja.com. 
Владельцы объясняют это расширением спектра услуг. В этом 
разделе говорится только о первоначальных услугах по архива- 
ции сообщений из сетевых конференций и поиску в архивах. 


На этом сайте хранятся архивы примерно 45000 дискуссионных форумов, 
включая конференции Usenet и собственные конференции Deja Community 
Discussions. Владельцы Deja.com утверждают, что примерно две трети всех архивов 
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составляют сообщения из конференций Usenet. На конец 1999 года в архивах хра- 
нились сообщения, начиная с марта 1995 года. 

Поисковая система сайта Power Search позволяет искать ответ на конкретный 
вопрос или информацию по некоторой проблеме в отдельной конференции, в груп- 
пе или даже во всех конференциях по ключевому слову, теме, автору или диапазону 
дат. Второй ценный ресурс — это список ресурсов по TCP/IP (TCP/IP Resources 
List) Юри Раца (Uri Raz), который каждые две недели рассылается в конферен- 
цию comp.protocols.tcp-ip и некоторые более специальные. Этот список — отличная 
отправная точка для тех, кто ищет конкретную информацию или общий обзор 
TCP/IP и соответствующих АР]. 

В списке имеются ссылки на книги по этому вопросу и другим, касающимся 
сетей; онлайновые ресурсы (к примеру, страницы ТЕТЕ и сайты, где размещаются 
FAQ); онлайновые книги и журналы, учебники по TCP/IP; источники информа- 
ции по протоколу IPv6; домашние страницы многих популярных книг по сетям; 
домашние страницы книжных издательств; домашние страницы проекта СМО 
и открытых операционных систем; поисковые машины с описанием способов ра- 
боты с ними и конференции, посвященные сетям. 

Самая последняя редакция списка находится на сайтах: 


a http://www.private.org.il/tcpi : 
a http://www.best.com.il/- e i ce 


Также информация может быть загружена ro ЕТР с сайтов: 


a ftp: ited senet-by- answers/i t/tcp-i source- 
list; 
с ftp;//rtfm.mit.edu/pub/usenet-by-hierarc rotocols/tcp-ip/TCP- 


IP. Resources. List. 


Особую ценность списку ресурсов по TCP/IP придает тот факт, что автор pe- 
гулярно обновляет его. Это немаловажно, так как ссылки в Web имеют тенденцию 
быстро устаревать. 


Приложение 1 


Вспомогательный код для UNIX 


Заголовочный файл etcp.h 


Почти все программы в этой книге начинаются с заголовочного файла etcp.h 
(листинг II1.1). Он подключает и другие необходимые файлы, в том числе skel.h 
(листинг П2.1), а также определения некоторых констант, типов данных и прото- 
ТИПОВ. 


Листинг ПТ. 1, Заголовочный файл etcp.h 


etcp.h 
Kifndef | ETCPH.. 
#define |, ETCPBH. 


/* Включаем стандартные заголовки. */ 


#1ис1аае «errno.h» 
#include <stdlib.h> 
#include <unistd.h> 
#include <stdio.h> 
#include <stdarg.h> 
#include <string.h> 
#include <netdb.h> 
#include «signal.h» 
#include «fcntl.h» 
#1пс1ае «sys/socket.h» 
#include «sys/wait.h» 
#include <sys/time.h> 
#include <sys/resource.h> 
#include «sys/stat.h» 
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18 £include «netinet/in.h» 

19 £include «arpa/inet.h» 

20 &include "skel.h" 

21 #define TRUE 1 

22 4$define FALSE 0 

23 #define NLISTEN 5  /* Максимальное число ожидающих соединений. */ 
24 #define NSMB 5 /* Число буферов в разделяемой памяти. */ 
25 #аеЕ1пе SMBUFSZ256/* Размер буфера в разделяемой памяти. */ 
26 extern char *program name; /* Для сообщений об ошибках. */ 
27 s$ifdef | УВА 
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28 #define bzero(b,n) memset( ( b ), 0, (n) ) 
29 #endif 
30 typedef void ( *tofunc t )( void * ); 


31 void error( int, int, char*, ... ); 
32 int readn( SOCKET, char *, size t ); 
33 int readvrec( SOCKET, char *, size t ) 
34 int readcrlf( SOCKET, char *, size t ); 
35 int readline( SOCKET, char *, size t ) 
36 int tcp server( char *, char * ); 
37 int tcp client( char * 
38 int udp server( char *, char * ); 
39 int udp client( char *, char *, struct sockaddr, in * ); 
40 int tselect( int, fd set *, fd set *, ѓа set *); 
41 unsigned int timeout( tofunc t, void *, int ); 
42 void untimeout( unsigned int ); 
43 void init smb( int ); 
44 void *smballoc( void ); 
45 void smbfree( void * ); 
46 void smbsend( SOCKET, void * ); 
47 void *smbrecv( SOCKET ); 
48 void set, address( char *, char *, struct sockaddr in *, char * ); 
49 #endif /* , ETCP_H_ */ 

etcp.h 


Функция daemon 


Функция daemon, которая использована в программе tcpmux, входит в стан- 
дартную библиотеку, поставляемую с системой BSD. Для систем ЗУ КА приводит- 
ся версия, текст которой показан в листинге П1.2. 


Листинг [11.2. Функция daemon 


daemon.c 

1 int daemon( int nocd, int noclose ) 

2 { 

3 struct rlimit rlim; 

4 pid_t pid; 

5 int i; 

6 umask ( O ); /* Очистить маску создания файлов. */ 

7 /* Получить максимальное число открытых файлов. */ 

8 if ( getrlimit( RLIMIT NOFILE, &rlim ) < 0) 

9 error( 1, errno, "getrlimit failed" ); 

10 /* Стать лидером сессии, потеряв при этом управляющий терминал... */ 

11 pid = fork(); 

12 if ( pid < 0 j 

13 return -1; 

14 if € pid != 0) 

15 exit( 0 ); 
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16 
17 


18 
19 
20 
21 
22 
23 


24 


25 
26 


27 
28 
29 
30 
31 


32 
33 


setsid(); 
/* ... и гарантировать, что больше ero не будет. */ 


signal( SIGHUP, SIG. IGN ); 
pid = fork(); 
if ( pid < 0 ) 
return -1; 
if ( pid != 0) 
exit( 0 ); 


/* Сделать текущим корневой каталог, если He требовалось обратное */ 


if ( !nocd ) 
charrt "/*" ); 
/* 
* Если нас He просили этого не делать, закрыть все файлы. 
* Затем перенаправить Stdin, stdout и stderr 
х Ha /dev/null. 
ЫА 


if ( !пос1оѕе ) 


( 


34 Sif 0 /* Заменить на 1 для закрытия всех файлов. */ 


35 if ( rlim.rlim max == RLIM INFINITY ) 
36 rlim.rlim, max = 1024; 

37 for (і = 0; і < rlim.rlim max; 1++ ) 
38 close( i ); 

39 #епа1Е 

40 1 = open( "/dev/null", O RDWR ); 

41 if (i«0) 

42 return -1; 

43 dup2( i, 0 ); 

44 dup2t( i, 1 ); 

45 dđup2( i, 2 ); 

46 if (i>2) 

47 close( i ); 

48 ) 


49 return 0; 


50 } 


Ум ааето.с 


Функция signal 

В этой книге уже упоминалось, что в некоторых версиях UNIX функция signal 
реализована на основе семантики ненадежных сигналов. В таком случае для полу- 
чения семантики надежных сигналов следует использовать функцию sigaction. 
Чтобы повысить переносимость, необходимо реализовать signal с помощью 
sigaction (листинг П1.3) 
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Листинг [11.3. Функция signal 


signal.c 
/* signal - надежная версия для SVRAÁ и некоторых других систем. */ 
1 typedef void sighndlr t( int ); 
2 sighndlr.t *signal( int sig, sighndlr t *hndlr ) 
3 { 

struct sigaction act; 

struct sigaction xact; 


act.sa, flags = 0; 


4 

5 

6 act.sa handler = hndlr; 

7 

8 sigemptyset( &act.sa, mask ); 


9 if ( sigaction( sig, &act, &xact ) < 0 ) 
10 return SIG. ERR; 

11 return xact.sa handler; 

12 ) 


signal.c 


Приложение 2 


Вспомогательный код для Windows 


Заголовочный файл skel.h 


Для компиляции примеров программ на платформе Windows вы можете 
пользоваться тем же файлом etcp.h, что и для UNIX (листинг П1.1). Вся систем- 
но зависимая информация находится в заголовочном файле skel .h, версия KOTO- 
poro для Windows приведена в листинге II2.1. 


Листинг П2. 1. Версия skel.h для Windows 
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*ifndef |, SKELH . 
#define |, SKELH . 


/* Версия Winsock. 


#1пс1аае «windows.h» 
#include «winsock2.h» 


struct timezone 


#define 
#define 
#define 


#define 


#define 
#define 
#define 
#define 
#define 
#define 


#endif 


tz minuteswest; 
tz dsttime; 


unsigned int u int32 t; 


EMSGSIZE 
INIT() 
EXIT (s) 
CLOSE(s) 


errno 


set errno(e) 
isvalidsock(s) 
bzero(b,n) 


sleep(t) 
WINDOWS 


/* |. .SKEL HJ */ 


WSAEMSGSIZE 
init( argv ): 


do ( WSACleanup():; 


while (0) 


if ( closesocket( s ) 


error( 1, 


errno, 


( GetLastError() ) 


SetLastError( 
( (s) 
( (5E; 1 
Sleep( ( t ) 


(e)) 


n) ) 
* 1000 ) 


Функции совместимости c Windows 


В листинге [12.2 приведены различные функции, которые использованы 
в примерах, но отсутствуют в Windows. 


exit( 


) 


\ 


!- SOCKET ERROR ) 


( 


S 


) 


)i 


skel.h 


ГАХ 


"ошибка вызова Close") 


skel.h 
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wincompat.c 
1 $&include «sys/timeb.h» 

2 include "etcp.h" 

3 #ınclude «winsock2.h» 


4 $define MINBSDSOCKERR ( WSAEWOULDBLOCK ) 

5 £$define MAXBSDSOCKERR ( MINBSDSOCKERR + \ 

6 ( sizeof( bsdsocketerrs ) / \ 

7 sizeof( bsdsocketerrs[ 0 ] ) ) ) 


8 extern int sys nerr; 

9 extern char *sys errlist[]; 
10 extern char *program name; 
11 static char *bsdsocketerrs[] - 


12 { 

13 "Resource temporarily unavailable", /* Ресурс временно недоступен. */ 
14 "Operation now in progress", /* Операция начала выполняться. */ 
15 "Operation already in progress", /* Операция уже выполняется. */ 

16 "Socket operation on non-socket", /* Операция сокета He над сокетом. */ 
17 "Destination address required", /* Нужен адрес назначения. */ 

18 "Message too long", /* Слишком длинное сообщение. */ 

19 "Protocol wrong type for socket", /* Неверный тип протокола для сокета. */ 
20 "Bad protocol option", /* Некорректная опция протокола. */ 
21 "Protocol not supported", /* Протокол He поддерживается. */ 
22 "Socket type not supported", /* Тип сокета He поддерживается. */ 
23 "Operation not supported", /* Операция He поддерживается. */ 
24 "Protocol family not supported", /* Семейство протоколов He */ 


/* поддерживается. */ 
25 "Address family not supported by protocol family", /* Адресное семейство */ 
/* не поддерживается семейством протоколов*/ 


26 "Address already in use", /* Адрес уже используется. */ 

27 "Can't assign requested address", /* He могу выделить затребованный */ 
/* адрес. */ 

28 "Network is down", /* Сеть He работает. */ 

29 "Network is unreachable", /* Сеть недоступна. */ 


30 "Network dropped connection on reset", /* Сеть сбросила соединение */ 
/* при перезагрузке. */ 
31 "Software caused connection abort", /* Программный разрыв соединения. */ 


32 "Connection reset by peer", /* Соединение сброшено другой */ 
/* стороной. */ 

33 "No buffer space available", /* Нет буферов. */ 

34 "Socket is already connected", /* Сокет уже соединен. */ 

35 "Socket is not connected", /* Сокет He соединен. */ 


36 "Cannot send after socket shutdown", /* He могу послать данные после */ 
/* размыкания. */ 

37 "Too many references: can't splice", /* Слишком много ссылок. */ 

38 "Connection timed out", /* Таймаут на соединении. */ 

39 "Connection refused", /* B соединении отказано. */ 

40 "Too many levels of symbolic links", /* Слишком много уровней */ 
/* символических ссылок. */ 


41 "File name too long", /* Слишком длинное имя файла. */ 
42 "Host is down", /* Хост не работает. */ 

43 "No route to host" /* Нет маршрута к хосту. */ 

44 }; 


45 void init( char **argv ) 
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46 { 

47 WSADATA wsadata; 

48 ( program name = strrchr( argv[ 0 |, '\\' ) ) ? 
49 program namet* : ( program name = argv[ 0 ] ); 
50 WSAStartup( MAKEWORD( 2, 2 ), &wsadata ); 

51 } 


52 /* inet aton - версия inet aton для SVr4 и Windows. */ 
53 int inet aton( char *cp, struct in addr *pin ) 


54 ( 

55 int rc; 

56 rc = inet addr( cp ); 

57 if ( rc == -1 && strcmp( cp, "255.255.255.255" ) ) 
58 return 0; 

59 pin-»s, addr = rc; 

60 return 1; 

61 ) 


62 /* gettimeofday - для tselect. */ 
63 int gettimeofday( struct timeval *tvp, struct timezone *tzp ) 


64 ( 

65 struct бітер tb; 

66 .ftime( &tb ); 

67 if ( tvp) 

68 ( 

69 tvp-»tv sec = tb.time; 

70 tvp-»tv usec = tb.millitm * 1000; 
71 ) 

72 if ( б2р ) 

73 { 

74 tzp-»tz minuteswest = tb.timezone; 
75 tzp-»tz dsttime = tb.dstflag; 

76 } 

77 } 


78 /* strerror - версия, включающая коды ошибок Winsock. */ 
79 char *strerror( int err ) 


80 ( 
81 if ( err »- 0 && err « sys nerr ) 
82 return sys errlist[ err ]; 
83 else if ( err »- MINBSDSOCKERR && err « MAXBSDSOCKERR ) 
84 return bsdsocketerrs[ err - MINBSDSOCKERR ]; 
85 else if ( err -- WSASYSNOTREADY ) 
86 return "Network subsystem is unusable"; 
/* Сбетевая подсистема неработоспособна. */ 
87 else if ( err == WSAVERNOTSUPPORTED ) 
88 return "This version of Winsock not supported"; 
/* Эта версия Winsock He поддерживается. */ 
89 else if ( err -- WSANOTINITIALISED ) 
90 return "Winsock not initialized"; 
/* Winsock He инициализирована. */ 
91 else 
92 return "Unknown error"; 
/* Неизвестная ошибка. */ 
93 } 


wincompat.c 
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